[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libusb+librump patch
From: |
Olaf Buddenhagen |
Subject: |
Re: libusb+librump patch |
Date: |
Mon, 19 Oct 2015 12:26:07 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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-
- libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/08
- Re: libusb+librump patch, Robert Millan, 2015/10/08
- Re: libusb+librump patch, Antti Kantee, 2015/10/08
- Re: libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/14
- Re: libusb+librump patch, Antti Kantee, 2015/10/14
- Re: libusb+librump patch, Olaf Buddenhagen, 2015/10/16
- Re: libusb+librump patch, Antti Kantee, 2015/10/17
- Re: libusb+librump patch,
Olaf Buddenhagen <=
- Re: libusb+librump patch, Antti Kantee, 2015/10/19
- Re: libusb+librump patch, Olaf Buddenhagen, 2015/10/25
- Re: libusb+librump patch, Antti Kantee, 2015/10/26
Re: libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/14