On Sun, 14 Apr 2002 23:51, David Brownell wrote:
> > 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 ...
It isn't that much legacy. The only hiddev programs that I know of are apcupsd
and NUT.
> 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).
Thanks for volunteering :)
> > uint16_t vendor;
> > uint16_t product;
> > uint16_t version;
>
> Stuffing those into 16 bits each seems a USB-ism, or
> maybe PCI-ism.
Err sure, but they _are_ direct analogs of USB descriptors (idVendor,
idProduct and bcdDevice from USB spec, Chapter 9 - table 9-7 in the USB 1.1
spec). Is moving them to the low bytes in a uint32_t meant to make for better
cache performance?
> > uint32_t num_applications;
> > };
>
> Too bad we can't use "u32" style typedefs except in-kernel,
> I happen to find all "*_t" typedefs ugly ... :)
Time to get used to it. It is called <stdint.h>, after all :)
> > 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.
What say the subsytem maintainer and driver maintainer?
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
