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

[Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

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.

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).

So, should we start perhaps by reworking the relationship between usbd
and the drivers? I don't really know.


[-- Attachment #2: Type: message/rfc822, Size: 4174 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: usbd - revision (Was: [9fans] USB developments)
Date: Thu, 15 Jan 2004 12:30:09 +0200
Message-ID: <20040115123004.D25947@cackle.proxima.alt.za>

On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote:
>
> #U, does mostly what it does, but stays appart of csp definitions.

I presume we'll look at this later, I'm sure there's a bit of work
needed here.

> usbd: simply configures the device and reads a usbdb file to
> learn which program is to be used for each csp.
> usbd: starts those programs when a new csp is noticed.

Let me see if I understand this correctly.  I would remove the initial
configuration from the kernel driver (#U) and delay it until usbd is
activated, although it's not (yet) clear to me whether the code needs
to reside in the kernel, in which case an "enumerate" function would
be implemented in #U and would return, through the control or status
file, the list of enumerated devices, each uniquely identifiable (by
numeric index seems good enough).

Let me stop here.  Have I explained how I see things properly?  How
do others suggest I tackle the above?

Next, we need to looks at /lib/usbdb, establish s tentative format and
a set of routines to read it.  Is that what aux/vga does?  How much
can we copy from there?

I then expect the ipconfig-like operation that Richard Miller suggest
could use /dev/sdctl needs to be implemented.  As Richard suggests,
this need not happen in a first phase, although I find it hard to
implement something knowing I'll do it differently soon enough.

My vote with Nemo about the plumber, which is not to say that plumbing
is not the right principle to employ.

Here I pause.  I think I need some input before proceeding, so feel
free to mail me, privately or publicly.  If private, make sure you
let me know if you don't want to be quoted in public.  And don't count
on me not making mistakes, with advance apologies right now :-)

++L