On 19/10/15 10:26, Olaf Buddenhagen wrote:
Not sure how much pluggability you would gain [...] meaning if you
could use alternative implementations.
I don't expect to be using alternative implementations; but separation
of concerns can improve flexibility in other ways too...
Fault isolation is also a concern -- though not the primary goal of the
Hurd architecture.
What exactly are you trying to isolate faults from? If the bottom or
top layer of the USB stack fails, applications will still fail. Ok, if
the top layer has no PCI access, then maybe it can't misprogram the DMA
controller. But that would be a malicious attack, as the chances of the
top layer accidentally misprogramming DMA are astronomical. And then
you're better off trusting an IOMMU. So I'm not sure I'd put
indirection along the normal path for that case.
For the USB protocol splitting, you could run one rump kernel instance
so that it exports ugen, and another one which uses ugenhc and
provides the high-level drivers.
I suppose that's what you mentioned in an earlier discussion, regarding
use of libusb?...
No, libusb would run on top of the /dev/ugen provided by a rump kernel.
That different from running two rump kernel instances on top of each
other.
Yea, I can see why it would be attractive for plugging into the
intermediate protocol and providing the ability to translate it left
and right. However, I'm not sure it's a good approach if you want
things to, you know, work.
Why?
Well, for one, the ugen interface loses information over what is
available for the USB stack running on top of a "native" host
controller, so some of the bits in the ugenhc implementation are
creative protocol-handling-by-heuristics. I really can't recommend
using ugenhc in any scenario which involves something else than USB
driver debugging.
If your fs server does the appropriate block level caching, that
approach should be reasonably performant, too.
Let's pretend it does ;-)
If it doesn't, things will still work, and I doubt they'll be unusably slow.
