bug-hurd
[Top][All Lists]
Advanced

[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-



reply via email to

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