[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