On Sat, Mar 12, 2022 at 01:05:46PM +1300, Paulo Miguel Almeida 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)
For staging drivers, the user/kernel api usually needs to be changed, so yes, as long as you can change the tools that are being used to talk to this api, you should be fine. thanks, greg k-h