ioctl number change / backwards compatibility doubt

[Paulo Miguel Almeida]

On Mon, Jan 24, 2022 at 07:20:45AM +0100, Greg KH wrote:
> On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote:
> > On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote:
> > 
> > when you told me to look for the userspace tool that interfaced with the
> > ioctl, my interpretation was that you were referring to something akin
> > to what /usr/bin/uname utility is to the syscall uname. Please correct me 
> > if I'm wrong.
> > 
> > re: what calls the ioctl created by the driver.
> > 
> > I'm led to believe that users of this driver make ioctl sycall
> > invocations directly from their application's source code like this:
> > 
> > #include "pi433_if.h"		/* userspace driver header */
> > #include <sys/ioctl.h>		/* ioctl */
> > 
> > int file_desc = open("/dev/pi433.0", O_RDWR);
> > struct pi433_tx_cfg tx_cfg = {
> > 	.frequency = 433000000,
> > 	.bit_rate = 4800,
> > 	<omitted for brevity>...
> > };
> > 
> > int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg);
> > ....
> 
> Yes, sorry for the confusion, this is what I am referring to.  Where is
> that userspace code as that is the code you will be needing to change if
> you want to change this ioctl interface.
> 
> thanks,
> 
> greg k-h

Hi Greg, 

The original author replied my email with that question.  He sent me
some the code used to interface with char device, however, the source
code he provided me is already incompatible with the current version of
the driver:

#include "rfxx.h" (file header name has changed)

int main(int argc, char *argv[])
{
	...
	struct rfxx_send_config sendConfig; (struct name has changed)
	...
        fd = open("/dev/rf69_0.0", O_RDWR); *(char device name changed)*
	...
	sendConfig.data_mode = packet; *(property doesn't exist)*
        ...
	(IOCTL call has a different name)
	ret = ioctl(fd, RFXX_IOC_WR_SEND_CONFIG, &sendConfig);
        if (ret == -1)
	...
}

Assuming that I tweak these tools he provided me with and publish them,
will I then be able to tweak the structures passed back and forth via
ioctl? (do I need to change ioctl number in this case?) 

The reason why I'm asking this is because given the fact that other
developers could have written similar code for interfacing with the
driver (and that we will never know because code is proprietary), I
won't be sure that I've changed all occurences at the same time, right?

All in all, please correct if there are gaps in this train of thought.

- If a change doesn't break *compiled* code (such as struct renaming) 
then it's 'okay' to make the change ? (this has happened in the this
driver before)

Best regards,

Paulo Almeida