On Sun, Jul 21, 2019 at 11:15 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Sun, Jul 21, 2019 at 2:13 PM Masahiro Yamada > <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > On Sun, Jul 21, 2019 at 6:10 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Sun, Jul 21, 2019 at 5:45 AM Masahiro Yamada > > > <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > > > On Sat, Jul 20, 2019 at 10:55 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > On Sat, Jul 20, 2019 at 5:26 AM Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > > > > > Another example that I have no idea > > how it works: > > > > drivers/net/hamradio/yam.c > > > > yam_ioctl() reads data from user-space, > > but the data structures for ioctl are > > defined in include/linux/yam.h > > That is different: the hardware attaches to a serial port and may well > be usable, and the user space side just contains a copy of the header, > see https://github.com/nwdigitalradio/ax25-tools/tree/master/yamdrv Oh, I did not know that user-space had a copy of that. > > If we want to fix this, we could move it > > to include/uapi/linux/yam.h > > We could do that, or just leave it alone, as nobody would > tell the difference. When we are changing structures in uapi, it is very likely a red alert. On the other hand, we can change code outside of uapi more safely. One benefit of uapi is we can catch the compatibility level from the directory path. > > > But, if nobody has reported any problem about this, > > it might be a good proof that nobody is using this driver. > > > > Maybe, can we simply drop odd drivers?? > > Both the kernel driver and the user space side have a maintainer, and > I see no indication that it is actually broken. The driver is clearly > a relic from old times (earlier than 2.4) and we would not merge > this driver today. > > It seems more useful to keep looking for drivers with a platform_data > header file that is no longer included by any platform for candidates > that may be obsolete. OK. Thanks. -- Best Regards Masahiro Yamada
