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@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
