Re: Device interfaces (was: USB Mass Storage with rump)

[Samuel Thibault]

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 here. Rather, the USB mass storage server(s) would
> > > export UNIX device nodes, which ext2fs/libstore can already deal with
> > > AFAIK.
> > 
> > But the fs RPC interface is much more involved to implement than the
> > device RPC interface.
> 
> Is it really?

Yes.

> While I haven't implemented a trivfs translator doing actual file I/O
> yet, they do seem simple enough to me... Or am I missing something?

Simple enough, but really less simple than device. Device is only
device_open/close, device_read/write, and set/get_status. trivfs
apparently has at least modify_stat, io_read/write, readable, select,
seek, file_set_size, owner, io_map, etc., most of which make very little
sense to a disk driver, and requires offset-to-block conversions.

> Also, it's a one-time effort. And it avoids the need to modify
> libstore/storeio.

The modification of libstore/storeio would be a one-time effort too, and
it would be useful for other use cases too (perhaps it even already has
the needed support actually)

> > Storeio already does the conversion nicely, why not reusing it?
> 
> Why introduce an unnecessary indirection,

It's not unnecessary. The conversion from io_read/write to block
read/write has to be done somewhere.

Possibly the code can be shared by stuffing the conversion layer as a
library, but really, providing a *really working* fs interface is much
more involved that just using storeio. In the end it's up to the person
who actually works on the code, but the easiest way to implement it is
using the device RPC and storeio. Perhaps libstore can be used as it is
to do the layering, I don't know.

Samuel