Hi, On Sat, Oct 17, 2015 at 01:16:38PM +0000, Antti Kantee wrote: > On 16/10/15 16:17, Olaf Buddenhagen wrote:
> Ok, so you'd decide how to limit the visibility and arbitrate bus > access in your PCI backend Yes, I believe that's the cleanest approach. (Not sure whether there is actually consensus on that -- though I'd hope so...) > I guess splitting the stack, especially in the case of USB, would be > possible, since the host controller is supposed to export "pipes" to > the rest of the USB stack. The next place you can split it is at the > USB device protocol level, a la ugen. And of top of that you really > already have the actual devices. I don't know enough about USB to have much of an opinion on that. I was only thinking of a single level of splitting -- probably the ugen one... > 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. > IIRC the pipes are specified in the USB standard, but I'm not sure if > they're really standard. Plus, you'd probably have to write some > code, and I'm not sure that code would be upstreamable, so you might > have to maintain it yourself too. That's a strong hint not to go down this route ;-) > 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?... > 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? > >However, Bruno (initially at least) doesn't actually want to do any > >of this. Rather, for a starting point he wants to try for the > >simplest possible architecture that somehow gives applications access > >to USB devices (especially mass storage devices). So he is thinking > >of something along the lines of what Robert did (giving mplayer > >access to USB sound devices through librump) -- in the case of USB > >mass storage, that would mean giving the filesystem servers access to > >USB storage devices through librump. He doesn't seem to be very clear > >on how that would work exactly, though... > > The rump kernel would export the block device, and you'd access it > from the fs server with rump_sys_read() and rump_sys_write(). Yeah, that sounds like what I would expect. > Notably, rump kernels support remote system calls, so driving things > remotely already works. The keyword is "sysproxy". That sounds quite interesting... Though it's already a step ahead of what Bruno wants to do initially. > If your fs server does the appropriate block level caching, that > approach should be reasonably performant, too. Let's pretend it does ;-) -antrik-
