On 20/07/14 11:03, Robert Millan wrote:
> I was reading through your blog and testing various functionality in RUMP,
> when I found
> that the passthrough USB Host controller wouldn't work on Linux hosts as it
> is based on
> ugen(4) interface.
>
> In your blog you talk about the loss of portability
> ("environment-agnosticism", as you put
> it), so I'm wondering if there might be a reason you preferred interfacing
> with ugen(4)
> directly (other than familiarity / etc) instead of the more portable libusb.
>
> I'm considering development of a libusb-based backend for RUMP, so if such
> backend is
> unsuitable for some reason, it'd be very useful for me to know in advance.
> I'm not very
> familiar with USB programming, so in case there's a showstopper it'd probably
> take me a
> while to notice .
Hi Robert,
I don't remember considering libusb. One reason could be that libusb is
not in the NetBSD base system, and back when I was writing ugenhc there
was no github infra, so everything had to more or less live and work
with the NetBSD base system.
I am not familiar with libusb and not sure if you could use it. ugenhc
requires fairly low-level access to the device; grep for the ioctl calls
in the driver. There's really only one way to find out. You might be
able to add Linux support to ugenhc fairly easily, though. I think the
ioctls and data structures are defined by USB instead of by NetBSD, so
you wouldn't need to do translating.
Now, I'm not really happy with how ugenhc turned out. It requires much
complex code to exist on the host, which isn't compatible with the goal
of rump kernels of running on a minimal host. The ugenhc driver itself
is also complex, making it hard to maintain. A better option might be
to access the USB device directly at the host controller level.
Specifically, for PCI devices, pci-userspace would need to handle
multifunction PCI devices correctly so that the USB companion host
controllers are correctly handled. The only real tradeoff I see is that
you need to do real DMA for host controller support as opposed to the
"pseudo-DMA" that ugenhc does.
That said, I'd welcome ugenhc (or libusbhc) support on non-NetBSD.
- antti
p.s. RUMP is a deprecated name, written language should prefer "rump
kernel". For one, in RUMP the U stood for Userspace, which is no longer
an all-encompassing description. Plus, the whole backronym was a bit
silly and not in the good way.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
