Hello,
I am a summer intern under the Outreachy program (returning to
software development after a long hiatus). I am developing a prototype
of a xen front/back end for a 9p file transport.
Since virtio is the most complete, and used, transport, I am using
that as a model.
I am encountering some problems that, to fix sanely, will require
making changes to virtio code. On the plus side, when I'm finished with
this project, any transport will be able to use the 9P server, with no
modification.
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.
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?
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.
Thank you for your time, and any help/insights you can provide.
Sincerely,
Linda Jacobson