Re: USB Mass Storage with rump

[Robert Millan]

El 19/09/15 a les 00:52, Olaf Buddenhagen ha escrit:
> On Wed, Sep 16, 2015 at 10:57:20PM +0200, Robert Millan wrote:
> > El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
>
> > > I'm interested in USB support.  I'd like to aim mass storage devices at
> > > first.
> >
> > For USB using Rump, I think most of the pieces exist already. Rump implements
> > the ugenhc NetBSD API, which is already supported by libusb, so if you want
> > to support all libusb-aware applications, I think you'd just need something
> > like:
> >
> > (cups|sane|whatever) ---> libusb ----> /dev/rumpusb (in Hurd VFS) ----> your 
> > translator ----> librump ----> /dev/ugenhc
>
> This looks nice for generic USB. I doubt we have a mass storage driver
> using libusb though? Rather, I guess it's something rump implements
> internally, and would be exposed through a different entry point?

Yes and no.

If you load *HCI support and USB mass storage into Rump, you can have
/dev/XXX pop up in the Rump namespace and that will be your disk node.
Then you can write a translator to link the host system into that disk
(or whatever way this is handled, does ext2fs open device nodes directly?).

Note, however, unless the same Rump instance also exports raw USB access as
described above, it will be the only possible user of USB in the system!

Since you most likely want to provide multiplexing, authorisation, etc, to
any application who wants to access USB, I wouldn't recommend to lump
USB mass storage and *HCI in the same Rump instance.

Instead, you could run a Rump instance with USB mass storage only which
uses libusb as backend rather than its own *HCI driver (but that requires
some coding work as it's currently not implemented ;-))

--
Robert Millan