ioctl number change / backwards compatibility doubt

Paulo Miguel Almeida paulo.miguel.almeida.rodenas at
Mon Jan 17 02:01:25 EST 2022

Hi everyone,


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


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


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?

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?

Best regards,

Paulo Almeida

More information about the Kernelnewbies mailing list