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
