9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] USB developments
Date: Thu, 15 Jan 2004 12:05:14 +0200	[thread overview]
Message-ID: <20040115120513.C25947@cackle.proxima.alt.za> (raw)
In-Reply-To: <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Thu, Jan 15, 2004 at 10:13:10AM +0100

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


  parent reply	other threads:[~2004-01-15 10:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-15  6:16 Lucio De Re
2004-01-15  8:23 ` Fco.J.Ballesteros
2004-01-15  8:42   ` Lucio De Re
2004-01-15  9:13     ` Fco.J.Ballesteros
2004-01-15  9:17       ` Fco.J.Ballesteros
2004-01-15 10:05       ` Lucio De Re [this message]
2004-01-15 10:23         ` Fco.J.Ballesteros
2004-01-15 13:02         ` Lucio De Re
2004-01-15 14:05           ` Richard Miller
2004-01-15 14:44             ` Lucio De Re
2004-01-15 14:56               ` Fco.J.Ballesteros
2004-01-15 15:20                 ` Lucio De Re
2004-01-15 15:41                   ` Fco.J.Ballesteros
2004-01-15 14:53             ` Fco.J.Ballesteros
2004-01-15 21:25             ` Dan Cross
2004-01-15 10:30       ` usbd - revision (Was: [9fans] USB developments) Lucio De Re
2004-01-15 10:46         ` Fco.J.Ballesteros
2004-01-15 11:47           ` Lucio De Re
2004-01-15 12:11             ` Charles Forsyth
2004-01-15 12:43               ` Lucio De Re
2004-01-15 18:01                 ` C H Forsyth
2004-01-15 19:10                   ` Lucio De Re
2004-01-15 20:24                     ` Charles Forsyth
2004-01-15 21:00                       ` Micah Stetson
2004-01-16  6:18                       ` Lucio De Re
2004-01-16  7:34                     ` Fco.J.Ballesteros
2004-01-16  7:38                     ` Fco.J.Ballesteros
2004-01-16  7:59                       ` Lucio De Re
2004-01-16 10:23                       ` Bruce Ellis
2004-01-16 10:32                         ` Lucio De Re
2004-01-16 10:39                           ` boyd, rounin
2004-01-16 10:45                           ` Richard Miller
2004-01-16 11:41                             ` Bruce Ellis
2004-01-16 11:50                               ` rog
2004-01-15  9:07   ` [9fans] USB developments Charles Forsyth
2004-01-15  9:18     ` Fco.J.Ballesteros
2004-01-15 10:39     ` Lucio De Re
2004-01-15 10:48       ` Richard Miller
2004-01-15  9:10 ` Richard Miller
2004-01-15  9:14   ` Fco.J.Ballesteros
2004-01-16  9:59 ` boyd, rounin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040115120513.C25947@cackle.proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).