[Top][All Lists]

[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: Fri, 16 Oct 2015 18:17:47 +0200
User-agent: Mutt/1.5.23 (2014-03-12)


On Thu, Oct 15, 2015 at 01:28:24AM +0000, Antti Kantee wrote:

> So do you want to implement your own drivers on top of libusb and use
> the rump kernel only for the host controller and device-independent
> USB support, or do you want to actually use the USB device-level
> drivers too (mass storage, etc)?  Or both, depending on the device?
> Or something completely different?  I don't know what the Hurd mindset
> is!

Well, I'm not sure which parts of the discussion you have already seen,
and which were on the Hurd list only -- so let me try to rehash the
entire story.

Let's start with the *ideal* architecture we would like to have. There
should be a PCI server process, which presents device files for every
PCI device present; along with a libpciaccess backend which can be
pointed at any of these device files, giving access to the associated
hardware device(s) -- and only these. For each device we would run a
Rump instance in another server, in turn presenting a device file giving
access to the device functionality. In some cases -- such as USB --
these first-level drivers would ideally only give raw access; and for
things like USB mass storage for example, we would in turn run separate
driver instances on top of the raw device files, which would finally
present device files giving access to the logical functionality. (Such
as block device files for storage devices; audio device files for sound
cards; etc.)

Now fully implementing this architecture would be pretty ambitious
(especially the last part about separating raw drivers from logical
drivers, as Rump itself doesn't have such a separation yet AIUI?) -- so
we might take some shortcuts: for example letting the first level
drivers directly export the higher-level functionality too. Or possibly
handling multiple devices in a single server instance.

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


reply via email to

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