> > > drivers/usb/bi device interfaces
> >
> > "bi"? Why not "di"?
>
> ...
> You would also end up describing them as Linux USB Device device drivers
> which is starting to get silly :-)
Which is why I've talked about "Device Controller Drivers", by
analogy to their corresponding "Host Controller Drivers". When
someone says "bi di" I think of multi-lingual text layout ... :)
A while back I concluded that "device driver" is a bad term
to use in the USB world, since any given communication
involves at least four drivers (!) for things that someone will
want to call a "device driver", thereby confusing someone:
- (host side) "interface driver", sometimes called "clients"
"class" drivers, or "vendor-specific" drivers
- (host side) "host controller driver" [HCD]
- (device side) "device controller driver" or whatever (*)
- (device side) "function driver"
HCDs are quite often PCI device drivers, and both of those
device side drivers might reasonably talk directly to some
kind of hardware. The controller driver certainly does.
- Dave
(*) Yes, I noticed the USB spec does talk about a "bus
interface" ... sloppy terminology choices there IMO,
ones we'd be better off not spreading in a Linux API.
As shown in figure 5-9, that "BI" layer appears on both
host and device sides. You'll notice obvious gaps
in the architectural presentation there, in that the data
just magically appears at the device logical layer. The
detail on the device side is much less than on the host
side, for such issues -- almost hand-wavey.
I suspect there was an assumption that USB functions
would normally be coded directly to register level APIs (for
specifc HW) at the "logical device" level. Vendors have
been known to embed assumptions about non-portable
implementations into specs like that ... it's a handy thing
when you value "implementation flexibility". :)
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
