From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOk2F-000689-N8 for qemu-devel@nongnu.org; Mon, 10 Aug 2015 06:10:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOk2B-0002OB-9G for qemu-devel@nongnu.org; Mon, 10 Aug 2015 06:10:27 -0400 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:38037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOk2A-0002MW-Tw for qemu-devel@nongnu.org; Mon, 10 Aug 2015 06:10:23 -0400 Received: by wicja10 with SMTP id ja10so18494918wic.1 for ; Mon, 10 Aug 2015 03:10:22 -0700 (PDT) Date: Mon, 10 Aug 2015 11:10:18 +0100 From: Stefan Hajnoczi Message-ID: <20150810101018.GC31433@stefanha-thinkpad.redhat.com> References: <55C4DB1B.1030304@jma3.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <55C4DB1B.1030304@jma3.com> Subject: Re: [Qemu-devel] virtio-9p List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Linda Cc: Julien Grall , Wei Liu , qemu-devel@nongnu.org --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 07, 2015 at 10:21:47AM -0600, Linda wrote: > As background, for the backend, I have been looking at the code, writ= ten > 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 betwe= en > 13 other files which handle all file access operations, converting them f= rom > 9p to Linux file system calls. > virtio-9p.c also contains some virtio-specific code (although most of > that is in virtio-device.c). >=20 > The problems I am encountering are the following: >=20 > 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 >=20 > 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 describ= ed > 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 --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVyHiKAAoJEJykq7OBq3PIwDoH+wc+U2z1g6pUWnoxLRx4tq/S VJnCpdYh8SvKT1B+9+nDdYu65vlVczUDit1ocpzXfHB45c0JhlQsWdwAm9yKVJHY xN3kokwtM0li7WtJEXZ/UPc9DqkL9z0IxpyD3iYxJ269MB4sMkEi38X84xMPJpL+ D8OBUiW3nki9SHUKg93OT/7KfevOoH/jVns2WVp/l/Rua89D8VZ007+dhdWA9KA+ NtA6pUOOf4s6FxsTxs3t5ZRd2VDnGvZeSEiQuJJimSMAq5tqIK19xheot+DagG/6 aGZ9jnxhGOwOK7zGXDuhoj4XjcJnaYYNwPDKt99Z3WWJVnOqJWfkKqIhKg8N6jo= =v7Rm -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef--