On 23/03/2017 14:55, Juergen Gross 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.
As long as the header changes rarely, I guess it's fine not to go through update-linux-headers.sh. Paolo > 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? > > > Juergen >