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 16:44:16 +0200	[thread overview]
Message-ID: <20040115164415.I25947@cackle.proxima.alt.za> (raw)
In-Reply-To: <fa94d592591f3ac06a396cd7db5e9bf1@hamnavoe.com>; from Richard Miller on Thu, Jan 15, 2004 at 02:05:53PM +0000

On Thu, Jan 15, 2004 at 02:05:53PM +0000, Richard Miller wrote:
>
> If usb mass storage needed to be "hooked" explicitly into the kernel,
> that would be the place to do it.  But I wasn't suggesting that it was
> the right thing to do.  I would still rather see usb mass storage
> provided as a self contained file server rather than as a "driver"
> wired into the kernel -- then a normal 9P interface suffices.
> What's the objection to this high level approach?
>
Maybe I'm just stupid, I just can't see how the high level approach
would provide the same functionality as #S without enormous repetition
as well as inefficiency on a data path that should be as fast as
possible.

- Oops, the above is a bit loaded, consider it toned down, there's
  not much "enormous" about it :-)

I also don't see that extending /sys/src/9/pc/sdata.c (and whatever
helpers apply) to deal with USB as the data path rather than the
IDE controller or, as already seems to be the case, PCMCIA devices,
would not lead to a cleaner architecture.  At some cost, without
a doubt, but making the most of Plan 9's lack of legacy would seem
appropriate here.

And as far as I am concerned, the top half of the ATAPI driver
could easily be either a kernel or a userland module, possibly even
both as is the case with your mass storage USB driver presently
and the corresponding ATAPI/SCSI functionality in the kernel.  I
want to avoid adding bulk to your driver when the functionality is
already in place in the ATAPI kernel module and I was a little
frightened when I noted that some USB/ATA interface chips do not
cope properly with SCSI commands, but implement the ATAPI ones
properly.  I may be misunderstanding matters totally, I grant, but
there aren't any shortcuts to finding out.

Or am I being utterly blind to something?  I suppose what I'm
suggesting is to streamline the kernel so the USB, PCMCIA and
IDE/SCSI bottom halves become as close to interchangeables as
possible.  It may be overkill, but once it's done, it may turn out
to be the type of investment that makes Plan 9 even more superior.

I'm curious as to whether it is even possible, but I have not heard
any strong objections yet, at least on its merit rather than on
its desirability from the point of view of minimising effort.

Sorry, the above is a bit disjointed, I hope others will be able
to piece the significant information together.  In summary, I find
USB surprisingly clean and I believe that Plan 9 is better suited
to the concept than any other OSes I am familiar with.  I need to
get more familiar with it and I'm willing to put a fair bit of
effort into it, but I'm not clever enough to do it properly without
understanding both USB and Plan 9 better.

++L


  reply	other threads:[~2004-01-15 14:44 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
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 [this message]
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=20040115164415.I25947@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).