ioctl number change / backwards compatibility doubt

[Paulo Miguel Almeida]

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