[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libusb+librump patch

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]