qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 1/8] xen: import ring.h from xen


From: Juergen Gross
Subject: Re: [Qemu-devel] [PATCH v4 1/8] xen: import ring.h from xen
Date: Thu, 23 Mar 2017 14:55:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 23/03/17 14:00, Greg Kurz wrote:
> On Mon, 20 Mar 2017 11:19:05 -0700
> Stefano Stabellini <address@hidden> 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 <address@hidden>
>> Reviewed-by: Greg Kurz <address@hidden>
>> CC: address@hidden
>> CC: address@hidden
>> ---
>> 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.

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




reply via email to

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