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.
No, it's not really about that -- I agree that accidental misprogramming
of unrelated hardware is a fairly unlikely scenario.
However, as we are working with an unsafe programming language here, all
kinds of basic programming bugs in *any* component can bring down the
entire stack. (And ofter open security exploits too.) Address space
(process) boundries tend to help a lot with isolating such problems.
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.
Yeah, but you mentioned at some point adding support for the
higher-level parts of the stack to use libusb as backend, so they could
run on top of another instance providing the lower-level functionality
via ugen? Or was that a misunderstanding?
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.
Ouch. Is that a problem with the specific ugen protocol, or a
fundamental limitation of any generic HC driver interface?...