[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 1/8] xen: import ring.h from xen
On 23/03/17 19:22, Stefano Stabellini wrote: > On Thu, 23 Mar 2017, Paolo Bonzini wrote: >> 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 <sstabellini@xxxxxxxxxx> 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 <stefano@xxxxxxxxxxx> >>>>> Reviewed-by: Greg Kurz <groug@xxxxxxxx> >>>>> CC: anthony.perard@xxxxxxxxxx >>>>> CC: jgross@xxxxxxxx >>>>> --- >>>>> 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. > > Very rarely, last time ring.h was changed was 2015, and to introduce a > new macro (which we don't necessarily need in QEMU). > > >>> 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? > > Yes, I think that is entirely possible: Xen and QEMU versions can mix > and match. > > Keeping in mind that the 9pfs backend has actually no build dependencies > on Xen, except for these new ring.h macros, we have the following > options: > > 1) we build the 9pfs backend only for Xen >= 4.9, because of the new > macros in ring.h that we need Right. You have sent 9pfs support patches for Xen tools. So obviously you need a proper Xen version to use 9pfs. Why not build qemu against it? Do you really expect a new Xen being used with an old qemu while wanting to use new features? That makes no sense for me. Juergen PS: added xen-devel as this should be discussed there, too. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |