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