Hi, On Tue, Oct 20, 2015 at 02:22:21AM +0000, Antti Kantee wrote: > On 19/10/15 10:26, Olaf Buddenhagen wrote:
> >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. 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 most microkernel systems, this is actually *the* single major selling point. For the Hurd, it's not a primary goal -- but still a nice bonus... > >>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?... -antrik-
