On Thu, 23 Mar 2017 14:55:26 +0100 Juergen Gross <jgr...@suse.com> wrote:
> On 23/03/17 14:00, Greg Kurz wrote: > > On Mon, 20 Mar 2017 11:19:05 -0700 > > Stefano Stabellini <sstabell...@kernel.org> wrote: > > > >> Do not use the ring.h header installed on the system. Instead, import > >> the header into the QEMU codebase. This avoids problems when QEMU is > >> built against a Xen version too old to provide all the ring macros. > >> > >> Signed-off-by: Stefano Stabellini <stef...@aporeto.com> > >> Reviewed-by: Greg Kurz <gr...@kaod.org> > >> CC: anthony.per...@citrix.com > >> CC: jgr...@suse.com > >> --- > >> NB: The new macros have not been committed to Xen yet. Do not apply this > >> patch until they do. > >> --- > > > > Looking at your other series for the kernel part of this feature: > > > > https://lkml.org/lkml/2017/3/22/761 > > > > I realize that the ring.h header from Xen also exists in the kernel tree... > > > > Shouldn't all the code that can be used in both kernel and userspace go to a > > header file under include/uapi in the kernel tree ? And then we would import > > it under include/standard-headers/linux in the QEMU tree and we could keep > > it > > in sync using scripts/update-linux-headers.sh. > > > > Cc'ing Paolo for insights. > > As Xen isn't part of the kernel we don't want that. You can use and/or > build qemu with xen-9pfs backend support on an old Linux kernel without > the related frontend. > Ok. > OTOH I don't see the advantage of not using the headers from Xen. This > is working for qdisk and pvusb backends and for all the Xen libraries. > Do you expect the 9pfs backend to be used for a qemu version built > against a Xen version not supporting that backend? > Not specifically, I was just feeling dubitative about that Xen header being manually copied to the kernel tree and also to the QEMU tree. > > Juergen >
pgp5mZXhcv4P5.pgp
Description: OpenPGP digital signature