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

[Stefano Stabellini]

On Wed, 29 Mar 2017, Paolo Bonzini wrote:
> On 29/03/2017 01:54, Stefano Stabellini wrote:
> >>> I understand your point of view, and honestly it wouldn't be a problem
> >>> doing it the way you suggested either. However, I think that going
> >>> forward it will be less of a maintenance pain to keep ring.h in sync,
> >>> compared to maintaining a versioned build dependency between Xen and
> >>> QEMU for the compilation of one PV backend. We do have version checks
> >>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
> >>> machine yet.
> >> For the pvUSB backend I just used a mandatory macro from the header for
> >> the #ifdef. The backend will signal support when it was defined during
> >> build and will refuse initialization otherwise. Xen tools are able to
> >> recoginze qemu support of the backend by looking into Xenstore.
> > 
> > What do you think of the following:
> 
> Let's just copy the header...

It's settled.

Thanks,

Stefano

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

[Paolo Bonzini]

On 29/03/2017 01:54, Stefano Stabellini wrote:
>>> I understand your point of view, and honestly it wouldn't be a problem
>>> doing it the way you suggested either. However, I think that going
>>> forward it will be less of a maintenance pain to keep ring.h in sync,
>>> compared to maintaining a versioned build dependency between Xen and
>>> QEMU for the compilation of one PV backend. We do have version checks
>>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
>>> machine yet.
>> For the pvUSB backend I just used a mandatory macro from the header for
>> the #ifdef. The backend will signal support when it was defined during
>> build and will refuse initialization otherwise. Xen tools are able to
>> recoginze qemu support of the backend by looking into Xenstore.
> 
> What do you think of the following:

Let's just copy the header...

Paolo

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

[Juergen Gross]

On 29/03/17 01:54, Stefano Stabellini wrote:
> On Tue, 28 Mar 2017, Juergen Gross wrote:
>> On 28/03/17 00:48, Stefano Stabellini wrote:
>>> On Mon, 27 Mar 2017, Juergen Gross wrote:
 On 24/03/17 18:37, Stefano Stabellini wrote:
> On Fri, 24 Mar 2017, Juergen Gross wrote:
>> 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  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 
>>> Reviewed-by: Greg Kurz 
>>> 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.
>>>
>>> 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.
>  
> Tools support is needed to setup the frontend/backend connection as
> usual, but that's not a requirement for building the 9pfs backend. In
> fact, the backend doesn't need any tools support for it to work. The
> macro themselves are just a convenience - the backend would work just
> fine without them. Why restrict the QEMU build gratuitously?

 You are duplicating a header without any real benefit I can see. This
 is adding future work for keeping both versions of the header in sync.

 In which scenario would you want qemu to support xen-9pfs without being
 built against a Xen version supporting xen-9pfs?

 I am not completely against copying the header, I just don't see an
 advantage for any distro or user in doing it.
>>>
>>> I understand your point of view, and honestly it wouldn't be a problem
>>> doing it the way you suggested either. However, I think that going
>>> forward it will be less of a maintenance pain to keep ring.h in sync,
>>> compared to maintaining a versioned build dependency between Xen and
>>> QEMU for the compilation of one PV backend. We do have version checks
>>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
>>> machine yet.
>>
>> For the pvUSB backend I just used a mandatory macro from the header for
>> the #ifdef. The backend will signal support when it was defined during
>> build and will refuse initialization otherwise. Xen tools are able to
>> recoginze qemu support of the backend by looking into Xenstore.
> 
> 
> What do you think of 

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

[Stefano Stabellini]

On Tue, 28 Mar 2017, Juergen Gross wrote:
> On 28/03/17 00:48, Stefano Stabellini wrote:
> > On Mon, 27 Mar 2017, Juergen Gross wrote:
> >> On 24/03/17 18:37, Stefano Stabellini wrote:
> >>> On Fri, 24 Mar 2017, Juergen Gross wrote:
>  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  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 
> > Reviewed-by: Greg Kurz 
> > 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.
> >
> > 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.
> >>>  
> >>> Tools support is needed to setup the frontend/backend connection as
> >>> usual, but that's not a requirement for building the 9pfs backend. In
> >>> fact, the backend doesn't need any tools support for it to work. The
> >>> macro themselves are just a convenience - the backend would work just
> >>> fine without them. Why restrict the QEMU build gratuitously?
> >>
> >> You are duplicating a header without any real benefit I can see. This
> >> is adding future work for keeping both versions of the header in sync.
> >>
> >> In which scenario would you want qemu to support xen-9pfs without being
> >> built against a Xen version supporting xen-9pfs?
> >>
> >> I am not completely against copying the header, I just don't see an
> >> advantage for any distro or user in doing it.
> > 
> > I understand your point of view, and honestly it wouldn't be a problem
> > doing it the way you suggested either. However, I think that going
> > forward it will be less of a maintenance pain to keep ring.h in sync,
> > compared to maintaining a versioned build dependency between Xen and
> > QEMU for the compilation of one PV backend. We do have version checks
> > in QEMU for Xen compatibility, but not for PV backends or the xenpv
> > machine yet.
> 
> For the pvUSB backend I just used a mandatory macro from the header for
> the #ifdef. The backend will signal support when it was defined during
> build and will refuse initialization otherwise. Xen tools are able to
> recoginze qemu support of the backend by looking into Xenstore.


What do you think of the following:

diff --git a/hw/9pfs/Makefile.objs 

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

[Juergen Gross]

On 28/03/17 00:48, Stefano Stabellini wrote:
> On Mon, 27 Mar 2017, Juergen Gross wrote:
>> On 24/03/17 18:37, Stefano Stabellini wrote:
>>> On Fri, 24 Mar 2017, Juergen Gross wrote:
 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  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 
> Reviewed-by: Greg Kurz 
> 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.
>
> 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.
>>>  
>>> Tools support is needed to setup the frontend/backend connection as
>>> usual, but that's not a requirement for building the 9pfs backend. In
>>> fact, the backend doesn't need any tools support for it to work. The
>>> macro themselves are just a convenience - the backend would work just
>>> fine without them. Why restrict the QEMU build gratuitously?
>>
>> You are duplicating a header without any real benefit I can see. This
>> is adding future work for keeping both versions of the header in sync.
>>
>> In which scenario would you want qemu to support xen-9pfs without being
>> built against a Xen version supporting xen-9pfs?
>>
>> I am not completely against copying the header, I just don't see an
>> advantage for any distro or user in doing it.
> 
> I understand your point of view, and honestly it wouldn't be a problem
> doing it the way you suggested either. However, I think that going
> forward it will be less of a maintenance pain to keep ring.h in sync,
> compared to maintaining a versioned build dependency between Xen and
> QEMU for the compilation of one PV backend. We do have version checks
> in QEMU for Xen compatibility, but not for PV backends or the xenpv
> machine yet.

For the pvUSB backend I just used a mandatory macro from the header for
the #ifdef. The backend will signal support when it was defined during
build and will refuse initialization otherwise. Xen tools are able to
recoginze qemu support of the backend by looking into Xenstore.


Juergen

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

[Stefano Stabellini]

On Mon, 27 Mar 2017, Juergen Gross wrote:
> On 24/03/17 18:37, Stefano Stabellini wrote:
> > On Fri, 24 Mar 2017, Juergen Gross wrote:
> >> 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  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 
> >>> Reviewed-by: Greg Kurz 
> >>> 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.
> >>>
> >>> 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.
> >  
> > Tools support is needed to setup the frontend/backend connection as
> > usual, but that's not a requirement for building the 9pfs backend. In
> > fact, the backend doesn't need any tools support for it to work. The
> > macro themselves are just a convenience - the backend would work just
> > fine without them. Why restrict the QEMU build gratuitously?
> 
> You are duplicating a header without any real benefit I can see. This
> is adding future work for keeping both versions of the header in sync.
> 
> In which scenario would you want qemu to support xen-9pfs without being
> built against a Xen version supporting xen-9pfs?
> 
> I am not completely against copying the header, I just don't see an
> advantage for any distro or user in doing it.

I understand your point of view, and honestly it wouldn't be a problem
doing it the way you suggested either. However, I think that going
forward it will be less of a maintenance pain to keep ring.h in sync,
compared to maintaining a versioned build dependency between Xen and
QEMU for the compilation of one PV backend. We do have version checks
in QEMU for Xen compatibility, but not for PV backends or the xenpv
machine yet.

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

[Juergen Gross]

On 24/03/17 18:37, Stefano Stabellini wrote:
> On Fri, 24 Mar 2017, Juergen Gross wrote:
>> 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  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 
>>> Reviewed-by: Greg Kurz 
>>> 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.
>>>
>>> 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.
>  
> Tools support is needed to setup the frontend/backend connection as
> usual, but that's not a requirement for building the 9pfs backend. In
> fact, the backend doesn't need any tools support for it to work. The
> macro themselves are just a convenience - the backend would work just
> fine without them. Why restrict the QEMU build gratuitously?

You are duplicating a header without any real benefit I can see. This
is adding future work for keeping both versions of the header in sync.

In which scenario would you want qemu to support xen-9pfs without being
built against a Xen version supporting xen-9pfs?

I am not completely against copying the header, I just don't see an
advantage for any distro or user in doing it.


Juergen

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

[Stefano Stabellini]

On Fri, 24 Mar 2017, Juergen Gross wrote:
> 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  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 
> > Reviewed-by: Greg Kurz 
> > 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.
> > 
> > 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.
 
Tools support is needed to setup the frontend/backend connection as
usual, but that's not a requirement for building the 9pfs backend. In
fact, the backend doesn't need any tools support for it to work. The
macro themselves are just a convenience - the backend would work just
fine without them. Why restrict the QEMU build gratuitously?

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

[Juergen Gross]

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  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 
> Reviewed-by: Greg Kurz 
> 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.
> 
> 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.

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

[Stefano Stabellini]

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  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 
> >>> Reviewed-by: Greg Kurz 
> >>> 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.

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

2) we import ring.h into QEMU so that ring.h it's not a build dependency
   anymore, then we can build the 9pfs backend against any Xen versions

3) we don't use the new macros, we write our own in QEMU, so that there
   is no build dependency and we can build the 9pfs backend against any Xen
   versions

I think they are all acceptable options. I went with 2) because I
thought it provides the best trade-off.

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

[Greg Kurz]

On Thu, 23 Mar 2017 15:19:28 +0100
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  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 
> >>> Reviewed-by: Greg Kurz 
> >>> 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
> 

If the header (or at least the parts that are relevant to QEMU) are stable
then my questioning can be ignored :)

Thanks.

--
Greg

> > 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
> >   



pgprOy7Lc9e5K.pgp
Description: OpenPGP digital signature

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

[Greg Kurz]

On Thu, 23 Mar 2017 14:55:26 +0100
Juergen Gross  wrote:

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

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

[Paolo Bonzini]

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  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 
>>> Reviewed-by: Greg Kurz 
>>> 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
> 

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

[Juergen Gross]

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

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

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

[Greg Kurz]

On Mon, 20 Mar 2017 11:19:05 -0700
Stefano Stabellini  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 
> Reviewed-by: Greg Kurz 
> 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.

> ---
>  hw/block/xen_blkif.h |   2 +-
>  hw/usb/xen-usb.c |   2 +-
>  include/hw/xen/io/ring.h | 455 
> +++
>  3 files changed, 457 insertions(+), 2 deletions(-)
>  create mode 100644 include/hw/xen/io/ring.h
> 
> diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
> index 3300b6f..3e6e1ea 100644
> --- a/hw/block/xen_blkif.h
> +++ b/hw/block/xen_blkif.h
> @@ -1,7 +1,7 @@
>  #ifndef XEN_BLKIF_H
>  #define XEN_BLKIF_H
>  
> -#include 
> +#include "hw/xen/io/ring.h"
>  #include 
>  #include 
>  
> diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
> index 8e676e6..370b3d9 100644
> --- a/hw/usb/xen-usb.c
> +++ b/hw/usb/xen-usb.c
> @@ -33,7 +33,7 @@
>  #include "qapi/qmp/qint.h"
>  #include "qapi/qmp/qstring.h"
>  
> -#include 
> +#include "hw/xen/io/ring.h"
>  #include 
>  
>  /*
> diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h
> new file mode 100644
> index 000..cf01fc3
> --- /dev/null
> +++ b/include/hw/xen/io/ring.h
> @@ -0,0 +1,455 @@
> +/**
> + * ring.h
> + * 
> + * Shared producer-consumer ring macros.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Tim Deegan and Andrew Warfield November 2004.
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_RING_H__
> +#define __XEN_PUBLIC_IO_RING_H__
> +
> +#if __XEN_INTERFACE_VERSION__ < 0x00030208
> +#define xen_mb()  mb()
> +#define xen_rmb() rmb()
> +#define xen_wmb() wmb()
> +#endif
> +
> +typedef unsigned int RING_IDX;
> +
> +/* Round a 32-bit unsigned constant down to the nearest power of two. */
> +#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 
> 0x1))
> +#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
> +#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
> +#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
> +#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
> +
> +/*
> + * Calculate size of a shared ring, given the total available space for the
> + * ring and indexes (_sz), and the name tag of the request/response 
> structure.
> + * A ring contains as many entries as will fit, rounded down to the nearest 
> + * power of two (so we can mask with (size-1) to loop around).
> + */
> +#define __CONST_RING_SIZE(_s, _sz) \
> +(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \
> + sizeof(((struct _s##_sring *)0)->ring[0])))
> +/*
> + * The same for passing in an actual pointer instead of a name tag.
> + */
> +#define __RING_SIZE(_s, _sz) \
> +(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
> +
> +/*
> + * Macros to make the correct C datatypes for a new kind of ring.
> + * 
> + * To make a new ring datatype, you need to have 

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

[Stefano Stabellini]

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 
Reviewed-by: Greg Kurz 
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.
---
---
 hw/block/xen_blkif.h |   2 +-
 hw/usb/xen-usb.c |   2 +-
 include/hw/xen/io/ring.h | 455 +++
 3 files changed, 457 insertions(+), 2 deletions(-)
 create mode 100644 include/hw/xen/io/ring.h

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index 3300b6f..3e6e1ea 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -1,7 +1,7 @@
 #ifndef XEN_BLKIF_H
 #define XEN_BLKIF_H
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 #include 
 
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 8e676e6..370b3d9 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -33,7 +33,7 @@
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qstring.h"
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 
 /*
diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h
new file mode 100644
index 000..cf01fc3
--- /dev/null
+++ b/include/hw/xen/io/ring.h
@@ -0,0 +1,455 @@
+/**
+ * ring.h
+ * 
+ * Shared producer-consumer ring macros.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Tim Deegan and Andrew Warfield November 2004.
+ */
+
+#ifndef __XEN_PUBLIC_IO_RING_H__
+#define __XEN_PUBLIC_IO_RING_H__
+
+#if __XEN_INTERFACE_VERSION__ < 0x00030208
+#define xen_mb()  mb()
+#define xen_rmb() rmb()
+#define xen_wmb() wmb()
+#endif
+
+typedef unsigned int RING_IDX;
+
+/* Round a 32-bit unsigned constant down to the nearest power of two. */
+#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 0x1))
+#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
+#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
+#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
+#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
+
+/*
+ * Calculate size of a shared ring, given the total available space for the
+ * ring and indexes (_sz), and the name tag of the request/response structure.
+ * A ring contains as many entries as will fit, rounded down to the nearest 
+ * power of two (so we can mask with (size-1) to loop around).
+ */
+#define __CONST_RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \
+   sizeof(((struct _s##_sring *)0)->ring[0])))
+/*
+ * The same for passing in an actual pointer instead of a name tag.
+ */
+#define __RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
+
+/*
+ * Macros to make the correct C datatypes for a new kind of ring.
+ * 
+ * To make a new ring datatype, you need to have two message structures,
+ * let's say request_t, and response_t already defined.
+ *
+ * In a header where you want the ring datatype declared, you then do:
+ *
+ * DEFINE_RING_TYPES(mytag, request_t, response_t);
+ *
+ * These expand out to give you a set of types, as you can see below.
+ * The most important of these are:
+ * 
+ * mytag_sring_t  - The shared ring.
+ * mytag_front_ring_t - The 'front' half of the ring.
+ * mytag_back_ring_t  - The 'back' half of the ring.
+ *
+ * To initialize a ring in your code you need to know the location and size
+ * of the shared memory area (PAGE_SIZE, for instance). To initialise
+ * the front half:
+ *
+ * mytag_front_ring_t front_ring;
+ * SHARED_RING_INIT((mytag_sring_t *)shared_page);
+ * FRONT_RING_INIT(_ring, (mytag_sring_t