On Sun, Oct 25, 2015 at 7:58 PM, Deepa Dinamani deepa.kernel@gmail.com wrote:
On Sat, Oct 24, 2015 at 1:38 AM, Arnd Bergmann arnd@arndb.de wrote:
On Saturday 24 October 2015 00:19:06 Arnd Bergmann wrote:
- Contact usb list about usbtest ioctl uses and about proposed new
ioctl.
Yes, but don't make this one a priority. Adding a new ioctl is just the icing on the cake, and that patch mainly serves to highlight the fact that the original API was implemented poorly and how it should have been done instead. It's more important for us to avoid making things worse with the 64-bit time_t change.
I've given this a little more thought now: I think we should support both variations of the current interface in both the kernel and in the official copy of the user space tool, for maximum compatibility.
If timeval remains as is, I don't see how user space needs to change. Agree that kernel module can support both so that either binary would work.
If we add another ioctl, that means we have to support all three variants in both kernel and user space for the foreseeable future, that's only worth it if we can add some real value in the new interface. Instead of a new ioctl, we could also choose to add a debugfs interface that might be easier to use. Still, that is only a mild improvement to a rarely used driver and a lot of work, so don't spend too much time on that one.
Ok. will let this one be for now.
Arnd
I looked at the spreadsheet(sheet 3). Nothing else actually needs timeval being exposed to userspace. Either whatever uses timeval, is only using it internally or uses time_t to user.
I submitted a v2 of the patch that doesn't require a new timeval struct accordingly.
-Deepa