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

[Lucio De Re <lucio@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