Olaf Buddenhagen, le Sat 26 Sep 2015 14:48:07 +0200, a écrit :
> On Thu, Sep 24, 2015 at 09:30:17AM +0200, Samuel Thibault wrote:
> > Olaf Buddenhagen, le Thu 24 Sep 2015 00:11:26 +0200, a écrit :
>
> > > As I already mentioned on IRC, I don't think we should emulate Mach
> > > device nodes at all
Hi,
On Thu, Sep 24, 2015 at 09:30:17AM +0200, Samuel Thibault wrote:
> Olaf Buddenhagen, le Thu 24 Sep 2015 00:11:26 +0200, a écrit :
> > As I already mentioned on IRC, I don't think we should emulate Mach
> > device nodes at all here. Rather, the USB mass storage server(s) would
> > export UNIX
El 24/09/15 a les 00:05, Olaf Buddenhagen ha escrit:
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 ;-))
Yeah, I guess that's the price to pay if
Olaf Buddenhagen, le Thu 24 Sep 2015 00:11:26 +0200, a écrit :
> On Sat, Sep 19, 2015 at 10:59:39AM +0200, Samuel Thibault wrote:
>
> > It'd probably be easy to make ext2fs open a device node, just like we
> > made pfinet do it.
>
> As I already mentioned on IRC, I don't think we should emulate M
Hi,
On Sat, Sep 19, 2015 at 10:59:39AM +0200, Samuel Thibault wrote:
> It'd probably be easy to make ext2fs open a device node, just like we
> made pfinet do it.
As I already mentioned on IRC, I don't think we should emulate Mach
device nodes at all here. Rather, the USB mass storage server(s) w
Hi,
On Sat, Sep 19, 2015 at 10:52:13AM +0200, Robert Millan wrote:
> 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.
Quite frankly, I wouldn't
Hi,
On Sat, Sep 19, 2015 at 11:57:03PM +0200, Robert Millan wrote:
> single Rump instance inside a single translator which exposes all of
> /dev in Rump namespace somewhere under host /dev hierarchy (e.g.
> /dev/rump/*).
This is certainly tempting, but also dangerous -- once a somewhat
working s
El 19/09/15 a les 10:59, Samuel Thibault ha escrit:
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 ;-))
Indeed. We can however start with an all-
Robert Millan, le Sat 19 Sep 2015 10:52:13 +0200, a écrit :
> 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 th
Olaf Buddenhagen, le Sat 19 Sep 2015 00:52:08 +0200, a écrit :
> 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?
I'd say so, yes.
Samuel
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
Hi,
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 impleme
12 matches
Mail list logo
