|
| From: | Antti Kantee |
| Subject: | Re: libusb+librump patch |
| Date: | Tue, 20 Oct 2015 02:22:21 +0000 |
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.
| [Prev in Thread] | Current Thread | [Next in Thread] |