Re: [Qemu-devel] virtio-9p

[Stefan Hajnoczi]

On Fri, Aug 07, 2015 at 10:21:47AM -0600, Linda wrote:
>     As background, for the backend, I have been looking at the code, written
> by Anthony Liguori, and maintained by Aneesh Kumar (who I sent this email
> to, earlier).  It looks to me (please correct me if I'm wrong, on this or
> any other point, below) as if Anthony wrote not just a backend transport
> layer, but the server as well.  AFAICT, there is no other Linux 9p server.

There are other Linux 9P servers.  At least there is diod:
https://github.com/chaos/diod

Anthony Liguori didn't write all of the virtio-9p code in QEMU.  Aneesh
Kumar, JV Rao, M. Mohan Kumar, and Harsh Prateek Bora did a lot of the
9P server development in QEMU.

Take a look at git shortlog -nse hw/9pfs

>     virtio-9p.c contains a lot of this server code, the rest spread between
> 13 other files which handle all file access operations, converting them from
> 9p to Linux file system calls.
>     virtio-9p.c also contains some virtio-specific code (although most of
> that is in virtio-device.c).
> 
> The problems I am encountering are the following:
> 
> 1.  In the virio-9p.h is a struct V9fsPDU that contains an element (in the
> middle of the struct) of type VirtQueueElement. Every 9p I/O command
> handler, as well as co-routines and support functions that go with them
> (i.e., a large part of the server), passes a parameter that is a struct
> V9fsPDU.   Almost all of these use only the variable that defines state
> information, and never touch the VirtQueueElement member.
>     The easiest fix for this is to have a separate header file with a
> #define GENERIC_9P_SERVER
>     Then I could modify the virtio-9p.h with:
>             #ifdef GENERIC_9P_SERVER
>                    a union of a void *, a char * (what I use), and a
> VirtQueueElement (guaranteeing the size is unchanged)
>             #else
>                     VirtQueueElement    elem;
>             #endif
> 
>     It's not my favorite construct, but it would involve the least amount of
> changes to the code.   Before I modify a header file, that code, I'm not
> touching, is dependent on, I wanted to know if this is an OK way.  If not,
> is there another way (short of copying fourteen files, and changing the
> names of all the functions in them, as well as the file names), that you
> would prefer?

What is the goal of your project?

If you just want a Linux 9P server, use diod.  You might be able to find
other servers that suit your needs better too (e.g. programming
language, features, etc).

An #ifdef is ugly and if you are going to submit code upstream then a
cleaner solution should be used.  Either separate a VirtIO9fsPDU struct
that contains the generic 9pfsPDU as a field (so that container_of() can
be used to go from 9pfsPDU back to VirtIO9fsPDU).  Or add a void* into
the generic 9pfsPDU so transports can correlate the generic struct with
a transport-specific struct.

>     2.  The other problem, is that most of the "server" functions described
> above, end by calling complete_pdu.   Complete_pdu (which is defined in
> virtio-9p.c) does many things that are generic, and also a few virito
> specific operations (pushing to the virtqueue, etc.).
>     Again, I can use a similar mechanism to the above.  Or is there some
> other way you'd prefer? I'm trying to find a way that has the least impact
> on virtio/qemu maintainers.

The generic PDU struct could have a .complete() function pointer.  This
is how the SCSI subsystem works, for example.  scsi_req_complete() calls
req->bus->info->complete(req, req->status, req->resid) so that the
bus-specific completion behavior is invoked.

Stefan

pgpY9FRTqNoWk.pgp
Description: PGP signature