On Mon, Jan 17, 2022 at 01:58:42PM +0100, Greg KH wrote: > Not many people ever look at that file, and it is ok to have conflicts > as the same tool should never have to handle multiple drivers where a > conflict happens. Noted > > 1: Given the driver's history and ioctl number conflit, is the backwards > > compatibility something to be kept or not to be taken into consideration > > as ioctl numbering rules weren't followed? > > Try to find out who is using these ioctls. If you can change the > userspace tool at the same time, all is fine. If not, then there can be > problems. Apologies for the delay, I had emailed the original author and I was waiting for his reply before I could answer this. It turns out I haven't gotten an official answer from him yet. (I do understand that he might be busy) I googled a fair bit of time and I'm 99% confident that there isn't such userspace/lib tool so I guess this will have done the hard way :( > > 2: The original author lists on the TODO file of the driver that 'he is > > afraid that using ioctl wasn't a good idea'. I pondered the alternatives > > and, *in case I can get rid of ioctl*, sysfs || configfs could be used. Does > > anyone suggests a different approach? > > Same answer as above, it depends on what userspace tool is using these > ioctls. Also it depends on what they do. Many informational ioctls can > just be replaced with sysfs files, and many configuration ioctls can be > replaced with configfs, but for other things, sometimes you need an > ioctl. > > So it depends. Try to get ahold of the userspace side and then you can > usually work it out. > Dan Carpenter suggested in one of patch reviews that we keep the ioctl for backwards compatibility but start a brand new sysfs implementation to encompass existing functionality to make it easier to add new features in future. I will wrap my head around it and send some RFC patches soon. thanks, Paulo Almeida _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
