At 2023-07-25 23:12:01, "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >On Tue, Jul 25, 2023 at 10:40:10PM +0800, Dingyan Li wrote: >> >> At 2023-07-25 22:08:44, "Oliver Neukum" <oneukum@xxxxxxxx> wrote: >> >On 25.07.23 15:54, Dingyan Li wrote: >> > >> >> If we can't "deprecate" ioctls, can we change the returned contents of existing ones? >> > >> >No. Absolutely not. That is totally unacceptable. It would be much >> >worse than just removing the support. >> > >> > Regards >> > Oliver >> >> Got it, I guess this is for backward-compatibility. >> >> I also have another thought. USBDEVFS_CONNINFO_EX is kind of special and >> used to retrieve contents of variable length. If you check proc_conninfo_ex(), >> I think maybe we can append a new member to "struct usbdevfs_conninfo_ex" >> without breaking backward-compatibility. > >How exactly would that work? Remember, new kernels still need to work >with old userspace code. > >greg k-h In proc_conninfo_ex(), the number of returned bytes is determined by the smaller number between sizeof(struct usbdevfs_conninfo_ex) and a user specified size. So if we only append new members to the end of struct usbdevfs_conninfo_ex, it won't impact the bytes in the beginning. For example, current sizeof(struct usbdevfs_conninfo_ex) is 24 bytes. Let's assume there is already some code using ioctl USBDEVFS_CONNINFO_EX and requesting a full size, which is 24 bytes. Now we append a new __u32 member called ssp_rate in the end of struct usbdevfs_conninfo_ex. For the old code, the meaning of the beginning 24 bytes is still the same. But for new code, we can now request a full size of 28 bytes. Regards, Dingyan
