ioctl number change / backwards compatibility doubt
Paulo Miguel Almeida
paulo.miguel.almeida.rodenas at gmail.com
Mon Jan 17 02:01:25 EST 2022
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?
More information about the Kernelnewbies