ioctl number change / backwards compatibility doubt

[Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>]

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

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?

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


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies