> Q2.
> Is there any reason why the structures in <linux/hiddev.h> don't use
> standardised types? For example, hiddev_devinfo should probably look
> something like:
> struct hiddev_devinfo {
(today, includes "bustype" field... relates to Q1)
> uint32_t busnum;
> uint32_t devnum;
My question is: why do we still have code in 2.5 that exposes
busnum and devaddr to user space code? We ought to be
getting rid of it, and just talking in terms of stable device IDs.
OK, maybe "legacy" APIs should linger, but ...
This is where the strings returned by usb_make_path() .would
naturally show up. They also happen to allow non-USB device
paths, which in this case just seems to me like the fallout one
would expect from any clean design.
> uint32_t ifnum;
This should arguably be part of an extended usb_make_path(),
since USB's interface abstraction is, well, USB-specific ... but it
corresponds reasonably well with the PCI "function" abstraction
(and the USB spec arguably uses "function" in that same way).
PCI "slot names" include functions (0..7 vs 0..256 for usb).
> uint16_t vendor;
> uint16_t product;
> uint16_t version;
Stuffing those into 16 bits each seems a USB-ism, or
maybe PCI-ism.
> uint32_t num_applications;
> };
Too bad we can't use "u32" style typedefs except in-kernel,
I happen to find all "*_t" typedefs ugly ... :)
> Do we want to change part of the interface, all of the interface, or none of
> the interface to userspace?
In usbdevfs, the control transfer field names have already changed,
so we have set a precedent.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
