ioctl number change / backwards compatibility doubt

[Rogério Valentim Feitoza da Silva]

On Friday, 11 March 2022, Paulo Miguel Almeida <
paulo.miguel.almeida.rodenas at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
No, it isn't OK. If a struct name is changed, it breaks source
compatibility.

-Rogério Valentim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220314/300962c8/attachment.html>