[OLPC-devel] Re: belt and suspenders...

John R. jhoger at gmail.com
Tue Jul 11 17:34:53 EDT 2006


On 7/11/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> John R. wrote:
> > On 7/11/06, Jim Gettys <jg at laptop.org> wrote:
> >
> >> Yeah, that was my guess.  And building a USB stack is *lots* of work.
> >>
> >
> > Is it a lot of work? I guess a general purpose USB stack is, but what
> > about just accessing USB storage?
>
> well, go for it, but I can only tell you that my one experience with
> "small, simple" USB stacks is in the bios world, and they don't work
> very well at all.
>
> The Linux USB stack is large and complex, and handles all kinds of
> corner cases, because USB is large and complex, and loaded with corner
> cases. It's not that linux USB is somehow a "bad" implementation, but
> more that USB is a real mess to cover completely. I had a lot of trouble
> with simple mass stores on the Insyde bios when I tried it, and all the
> little USB mass stores I had worked just fine in linux.
>
> ron
>
>

Yeah, I see what you're saying, corner cases are a pain and it's hard
to know what's there until one gets neck deep into it. Is the proposed
requirement to boot from any usb-storage device?  Can we just qualify
10 or 20 different makes/models and call it a day? Or would such a
driver really have to boot from anything that calls itself
usb-storage?

What we can do that Linux can't is remove any api layers, and
genericity. I imagine you're right that Linux USB isn't a bad or
bloated implementation, it's probably just generic. It's got to plug
and play with every type of USB device. For usb-storage devices it
must have to work with arbitrary file systems.

If we can construct the requirement as "load the first so many sectors
from a random sample of usb flash or hard drives formatted in a
particular way to RAM when nothing else is connected to the bus" I
think it's more likely to be doable.

-- John.



More information about the Devel mailing list