On Friday, 11 March 2022, Paulo Miguel Almeida <<a href="mailto:paulo.miguel.almeida.rodenas@gmail.com">paulo.miguel.almeida.rodenas@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 24, 2022 at 07:20:45AM +0100, Greg KH wrote:<br>
> On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote:<br>
> > On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote:<br>
> > <br>
> > when you told me to look for the userspace tool that interfaced with the<br>
> > ioctl, my interpretation was that you were referring to something akin<br>
> > to what /usr/bin/uname utility is to the syscall uname. Please correct me <br>
> > if I'm wrong.<br>
> > <br>
> > re: what calls the ioctl created by the driver.<br>
> > <br>
> > I'm led to believe that users of this driver make ioctl sycall<br>
> > invocations directly from their application's source code like this:<br>
> > <br>
> > #include "pi433_if.h"               /* userspace driver header */<br>
> > #include <sys/ioctl.h>              /* ioctl */<br>
> > <br>
> > int file_desc = open("/dev/pi433.0", O_RDWR);<br>
> > struct pi433_tx_cfg tx_cfg = {<br>
> >     .frequency = 433000000,<br>
> >     .bit_rate = 4800,<br>
> >     <omitted for brevity>...<br>
> > };<br>
> > <br>
> > int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg);<br>
> > ....<br>
> <br>
> Yes, sorry for the confusion, this is what I am referring to.  Where is<br>
> that userspace code as that is the code you will be needing to change if<br>
> you want to change this ioctl interface.<br>
> <br>
> thanks,<br>
> <br>
> greg k-h<br>
<br>
Hi Greg, <br>
<br>
The original author replied my email with that question.  He sent me<br>
some the code used to interface with char device, however, the source<br>
code he provided me is already incompatible with the current version of<br>
the driver:<br>
<br>
#include "rfxx.h" (file header name has changed)<br>
<br>
int main(int argc, char *argv[])<br>
{<br>
        ...<br>
        struct rfxx_send_config sendConfig; (struct name has changed)<br>
        ...<br>
        fd = open("/dev/rf69_0.0", O_RDWR); *(char device name changed)*<br>
        ...<br>
        sendConfig.data_mode = packet; *(property doesn't exist)*<br>
        ...<br>
        (IOCTL call has a different name)<br>
        ret = ioctl(fd, RFXX_IOC_WR_SEND_CONFIG, &sendConfig);<br>
        if (ret == -1)<br>
        ...<br>
}<br>
<br>
Assuming that I tweak these tools he provided me with and publish them,<br>
will I then be able to tweak the structures passed back and forth via<br>
ioctl? (do I need to change ioctl number in this case?) <br>
<br>
The reason why I'm asking this is because given the fact that other<br>
developers could have written similar code for interfacing with the<br>
driver (and that we will never know because code is proprietary), I<br>
won't be sure that I've changed all occurences at the same time, right?<br>
<br>
All in all, please correct if there are gaps in this train of thought.<br>
<br>
- If a change doesn't break *compiled* code (such as struct renaming) <br>
then it's 'okay' to make the change ? (this has happened in the this<br>
driver before)<br>
<br>
Best regards,<br>
<br>
Paulo Almeida<br>
<br>
<br>
______________________________<wbr>_________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.<wbr>org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">https://lists.kernelnewbies.<wbr>org/mailman/listinfo/<wbr>kernelnewbies</a><br>
</blockquote><div>No, it isn't OK. If a struct name is changed, it breaks source compatibility.</div><div><br></div><div>-Rogério Valentim </div>