> > Different terminology for the same thing would just be
> > confusing, for example... a USB "interface" should be
> > called the same thing everywhere, but seems like it's
> > become a "function" in this USBD code, while the
> > word "interface" is used to describe controllers
> > (host and device).
>
> There are two problems. First the USB specification usurped a lot of
> commonly used words and used them for new things.
This is a problem with almost every spec that doesn't
try to usurp new (previously nonsense) words ... and
that'd create its own set of headaches !! :)
I don't think that _in the USB context_ most of those
words should be at all confusing. But the ones you
mentioned that seem most important to everyone
not implementing internals (host or device controller
drivers, and API abstractions wrapping them) are:
Host, Device ... as you noted, these are asymmetric
in USB. There's a precise analogy to networking:
Client, Server. Once understood, I can't see this
as being confusing. (At least to anyone who's
beyond assuming a "server" is anything more
than a role in a particular interaction.)
Interface ... the word seems to have inherent confusion,
unless one takes care to be clear on context. In USB,
one or more interfaces are associated with each of a
device's configurations. Each interface is associated
with some protocol, often a standard one called a
"class" specification.
Hosts and devices agree on what each interface "means"
(and how to use it) else they couldn't communicate.
Function ... hardware/software that exposes one or more
interfaces. The "implementation" of those interfaces, in
some USB device.
This term is likely unfamilar to many host side USB
developers here -- we've not used it much yet, so it's
a good term to carefully define for device side APIs.
Maybe drivers/usb/functions for "function" drivers?
Client ... by definition, a USB host side driver, which talks
through an interface (to a function). I sometimes say
"interface driver" instead of "(client) device driver",
since USB devices can expose many interfaces
(even though many have just one).
I often come back to basic network architecture models
when I think of what the entire USB stack looks like. A
client runs on a host, and talks to a server (function) that
implements some interface (maybe a standard class).
The client isn't supposed to know or care about any of
the implementation details of the lower level protocol
stack (USB controllers, host or device sides) or how the
server ("function", like any other distributed object) is
implemented ... only how it responds to messages.
> > ... [ API convergence]...
> >
> > Maybe we can use this API to finally shrink and simplify the
> > URB model in the host side drivers ... convergence would
> > more naturally involve changes on _both_ sides.
> >
> > Plus [I] think that if, as Stuart said, he thinks it's a bit "over elaborated",
> > incremental integration (in simpler chunks) would be a good way
> > way to address some of those issues.
>
> I have two comments. As I suggested above there are two quite different
> stacks doing different things. Each implementing one end of the physical
> bus and logical connection. I think we can try and make terms and
> function (as in C function names) consistant. But there probably will
> still be two API's.
We could merge them to a fair degree, but there'd still be a clear
distinction between some host side activities and corresponding
device side ones.
I think all transfers except control (which is asymmetric) could
have a symmetric API and model: just queue transfer requests,
and get callbacks when the URBs complete (or abort).
Stuff like enumeration and, particularly, configuration would be a
different business. Systems could have multiple downstream
connectors if they're a host ... but it might actually be illegal to have
more than one upstream connector (devices talking to more than
one host).
> Not withstanding the previous paragraph things are going to be very
> interesting when we start to think of supporting the new USB On-The-Go
> chips.
Which is part of why I think we really _ought_ to think about shrinking
and simplifying the URB model, and aligning things quite closely.
> USB OTG defines devices that can be either a USB host or USB device
> depending on whether the A or B end of the cable is plugged into them.
> They have defined a mini A/B plug that can accept both and the
> host/device can determine whether they are the USB Host or USB Device
> by seeing which end of the cable is plugged in.
> ...
> So the bus interface driver and host interface drivers
[ ... purely internal to USB, all but invisible to interface drivers and to
function implementors ... these are the interfaces exposed only
to "usbcore" and its device side analogue ... ]
> need to be
> co-ordinated enough to be able to operate independantly and not
> interfere with each other when not needed.
Yes. And I'd extend that a bit: the co-ordination should be closer
than "not interfere". It would seem wrong to expect one driver to
use two different APIs to send a 4K of data on a bulk endpoint, one
for its host side role ("interface driver") and the other for its device
side role ("function driver").
But the current URB API is a bit fat for my taste. It deserves some
streamlining in 2.5, IMO ... particularly if we look forward to the
"On-The-Go" products that'll appear someday! :)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
