On Tue, Apr 02, 2002 at 10:40:08AM -0800, David Brownell wrote:
> > - do you want me to add this to the main kernel tree? It should
> > probably go somewhere like drivers/usb/device.
> Before it goes there, I thought I'd request some discussion
> and convergence of the API with what's already there.
> Easier to achieve that before integration than after.
>
> 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.
I try and keep the following straight by always putting USB in front of
them:
USB Device
USB Host
USB Device Descriptor
USB Configuration
USB Interface
Second the specification specifically uses different names for each end
of the architecture. The functionality and implementation at each end
is also different.
And again the USB specification overloads common terms so we end up
with:
USB Function
USB Client
USB Class
A USB Function driver implements a function (like network) on a USB
Device.
A USB Client driver implements something for a specific USB Device most
likely with a non standard configuration.
A USB Class driver implements something for a class of USB Devices using
a known standard.
> > - it looks like your usbd api is close to the same as the
> > existing usb api. Why not make it even closer to help provide
> > some "familiarity" when writing drivers for both sides of the
> > wire? For example, usbd_alloc_urb() takes 4 parameters, while
> > usb_alloc_urb() takes 2.
>
> Exactly: API convergence. Constants and structure defs
> (for descriptors etc) should be the same (common header?),
> there should NOT be two conflicting definitions of "URB",
> and so on.
>
> 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 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.
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.
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.
To make things even more interesting the two devices can use a Host
negotiation protocol to switch things around if they think that would be
a good idea.
So the bus interface driver and host interface drivers need to be
co-ordinated enough to be able to operate independantly and not
interfere with each other when not needed.
--
__O
Lineo - Where Open Meets Smart _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
