Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re <lucio@proxima.alt.za>]

On Thu, Jan 15, 2004 at 11:46:53AM +0100, Fco.J.Ballesteros wrote:
>
> I think the #U work is just to setup the bus and also to hardwire
> the endpoints (i.e. to service real usb interrupts as it's doing now,
> for performance). It should not depend on user programs, although
> they can for sure setup the endpoints and the like.
>
We have the interesting Plan 9 feature that the kernel need not be
used for separation of identity, everything the kernel can do, eve
can also do, specially as regards peripherals.  In Unix one moves
operations into the kernel as soon as they need to have more rights
than the average user.  In Plan 9 the only really reason for kernel
inclusion is efficiency: even interrupts could be handled by eve
processes.

What I'm trying to say is that we can put the bare essentials in
#U and delegate an unreasonable amount to usb/usbd.  But, to counter
this, I think enumeration, to the extent that it can be treated as
a generic operation, does belong in the kernel.  I would repeat my
suggestion that it be a #U operation triggered bu usbd, returning
a list of devices and hubs that can be used as a starting point
for further tasks.

With usb_enumerate() as a #U function, it may be possible as well
as necessary to include in the kernel code (is init(8) not a
possibility?) keyboard, screen and mouse initialisation and
configuration so as to be able to boot.  Nemo, your experience is
invaluable here, I must confess I didn't pay much attention at the
time you posted your findings as USB was nowhere on my horizon at
the time.

> Usbd is probably where the enumeration belongs, but I'd say that
> just that. The driver is the one who knows how to configure the device,
> once it has been started by usbd (which only needs to look at usbdb).
>
I think the code itself should live in #U; usbd invokes it thereafter,
the ideal time would be by blocking on a ctl read until #U detects
a bus change (is this a correct understanding?).  Usbd collects
the fresh list of hubs/functions on completion.  Mind you, #U may
as well do the enumeration itself, unblock usbd by posting the list
of

	devno -> (type, status)

on the ctl usbd is blocked on.  Too expensive, perhaps?  I'm thinking
of making the enumeration as simple as one can conceive, usbd can
then be forgiven for repeating some of the functionality.  If #U
only holds a list of 0 to 127 possible devices and an accurate
"condition", usbd can be expected to maintain the full bus description.
We can stop multiple instances of usbd occurring (we may be doing
this already?) by making sure that the #U/usbn files are single-open.

(Maybe I can try my hand at a #U that does little more than this,
right away?  Comments?)

> So, should we start perhaps by reworking the relationship between usbd
> and the drivers? I don't really know.
>
Somebody with a lot of USB experience should be looking at the
usbdb database, I think.  This is a long-term function, so it would
be nice to have a few volunteers, specially persons who already
have some experience interacting with USB device manufacturers.

I'd like to look at usbd in more detail, particularly trying to
understand how to separate its functionality along standard lines.
The device class bit is still very unclear to me, so I need to do
some further reading of the USB specification.

Those of us who have already looked at various devices may want to
suggest where they see the separation between function-specific
code and code that should be in usbd.  I'd like to hear from them
and tune usbd to suit.  This with a view to making the device driver
capable of being "mounted" on any USB stream, preferably with little
or no knowledge of the actual shape of the stream itself.  Even
the choice of alternative (the standard annoyingly adopted the
incorrect adjective "alternate" which I suppose I must force myself
to use in future) configurations should be delegated to /lib/usbdb
and usbd, in my premature opinion.

I'll dig into Richard Miller's mass-storage code and try to understand
where I'd hook into the ATAPI driver for my bit in the above.  I now
have two CBI devices, one ATA, the other flash memory card
reader/writer, so it's worth my while to do some digging.

Please keep the suggestions coming.  Specially if you see me stray off
the sensible path.  And don't let me get away with waffle, please pick
any nonsense I spout off here and correct me.

++L