From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] USB developments
Message-ID: <20040115120513.C25947@cackle.proxima.alt.za>
References: <20040115104258.A25947@cackle.proxima.alt.za> <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Thu, Jan 15, 2004 at 10:13:10AM +0100
Date: Thu, 15 Jan 2004 12:05:14 +0200
Topicbox-Message-UUID: b9236df4-eacc-11e9-9e20-41e7f4b1d025

On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote:
>
> Sure. I'm willing to open accounts here, although perhaps sources is
> a better place to do that.
>
Probably, if Bell Labs are willing and can keep it going.  Maybe
we ought to locate a mirror server for sources?  Anyone can provide
such a luxury?

> After taking a look to it all, I ended up thinking that the scheme should
> be like:
>
> #U, does mostly what it does, but stays appart of csp definitions.

Yep, sounds sensible.  But I'll get back to this in a moment.

> usbd: simply configures the device and reads a usbdb file to
> learn which program is to be used for each csp.

Mostly what I expect too, still with reservations.

> usbd: starts those programs when a new csp is noticed.

Let me call this "configure" because it needs a little bit of
thinking, in my opinion.

> drivers: are started always on a particular target, and work just
> for a particular device.
>
Presumably multiple instances if targets are duplicates.

> All of it started at boot time.
>
> For example, we have to keep an ugly sleep in boot.c to give
> usbd some time before usbhid starts. It would be better the other way.
>
I agree.  I haven't looked at your new keyboard stuff, but I plan to.

> I'd just modify usbd to start the driver when a device is first seen,
> then the driver can be responsible for killing himself, should the device
> go away. If the device comes back again, usbd could start the device
> again.
>
> Isn't that enough?

Well, my thinking (muddled as it is) was that the ATA/ATAPI driver
must somehow submit commands via the USB interface, which means that
if the ATAPI driver is not already split along these lines, it ought
to be and the top portion would then be linked to its bottom portion
or the USB driver depending on how it is to be used.

Am I making sense?

If I am, then usbd may as well spawn the command to link the top half
to the bottom half as the "configure" operation I was mentioning
earlier.

++L