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
