qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] virtio-9p


From: Linda
Subject: [Qemu-devel] virtio-9p
Date: Fri, 7 Aug 2015 10:21:47 -0600
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]