ioctl number change / backwards compatibility doubt

Greg KH greg at
Mon Jan 17 07:58:42 EST 2022

On Mon, Jan 17, 2022 at 08:01:25PM +1300, Paulo Miguel Almeida wrote:
> Hi everyone,
> Context:
> I've been working on a driver called pi433 in the staging area and it 
> basically exposes a char device so the user can read/write stuff to
> it while obtaining tx/rx configuration via ioctl calls.
> Tx/Rx configurations are both structs that (ideally) would be exposed
> to the userspace to let the developer to #include it on their code.
> Info that *might* be relevant about this driver:
> - This driver went straight to the staging area due to a few TODOs
>   listed by the original author. 
> - The ioctl Code and Seq numbers are conflicting with the ones listed
>   in the ioctl-numbers.rst

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.

> Problem:
> I realized that one of the structs used to pass/retrieve info needs
> to have some of its members changed (data type and etc)


> Questions:
> 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

> 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

So it depends.  Try to get ahold of the userspace side and then you can
usually work it out.


greg k-h

More information about the Kernelnewbies mailing list