On Mon, Feb 25, 2019 at 04:11:49PM +0000, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi () 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 <>
> > ---
> > 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
