Re: [PATCH v3 1/2] content: add virtio file system device

[Stefan Hajnoczi <stefanha@redhat.com>]

On Mon, Feb 25, 2019 at 04:11:49PM +0000, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > The virtio file system device transports Linux FUSE requests between a
> > FUSE daemon running on the host and the FUSE driver inside the guest.
> > 
> > The actual FUSE request definitions are not duplicated in the virtio
> > specification, similar to how virtio-scsi does not document SCSI
> > command details.  FUSE request definitions are available here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h
> > 
> > This patch documents the core virtio file system device, which is
> > functional but lacks the DAX feature introduced in the next patch.
> > 
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >  content.tex      |   3 +
> >  introduction.tex |   3 +
> >  virtio-fs.tex    | 196 +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 202 insertions(+)
> >  create mode 100644 virtio-fs.tex
> > 
> > diff --git a/content.tex b/content.tex
> > index 836ee52..ac41fdb 100644
> 
> > +The FUSE protocol documented in \hyperref[intro:FUSE]{FUSE} specifies the set
> > +of request types and their contents.  All request fields are little-endian.
> 
> FUSE doesn't seem to define it's endianness - and I'm not sure it's
> worth it for us to define it and do the work of adding a byteswapping
> shim.  It would be reasonably invasive in the kernel code to do that
> if we're the only user, and really I think the chances of having a
> cross-endian user are pretty slim; so adding invasive code for a
> non-existent user seems a bad thing.
> IMHO we should just stick with the existing FUSE definition; I believe
> it's possible to detect a byteswapped interface by validating the
> 'opcode' field of the fuse_in_header; existing daemons should just error
> on this; in the unlikely event that someone discovers they really want
> a cross endian implementation then they can add that byteswapping in
> their daemon.
> 
> We should still keep the virtio level little endian of course.

Sounds good to me but I will double-check the FUSE protocol to make sure
using the opcode field as a byte order mark will work.

Thanks, will fix in v4.

Stefan

Attachment: signature.asc
Description: PGP signature