Hi, 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... -antrik-
