Re: [Xen-devel] [PATCH 1/3] [RESEND v4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 17 Mar 2017, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 14, 2017 at 03:18:34PM -0700, Stefano Stabellini wrote:
> > This patch introduces macros, structs and functions to handle rings in
> > the format described by docs/misc/pvcalls.markdown and
> > docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
> > contains the indexes and the grant refs to setup two rings.
> > 
> >                Indexes page
> >                +----------------------+
> >                |@0 $NAME_data_intf:   |
> >                |@76: ring_order = 1   |
> >                |@80: ref[0]+          |
> >                |@84: ref[1]+          |
> >                |           |          |
> >                |           |          |
> >                +----------------------+
> >                            |
> >                            v (data ring)
> >                    +-------+-----------+
> >                    |  @0->4098: in     |
> >                    |  ref[0]           |
> >                    |-------------------|
> >                    |  @4099->8196: out |
> >                    |  ref[1]           |
> >                    +-------------------+
> > 
> > $NAME_read_packet and $NAME_write_packet are provided to read or write
> > any data struct from/to the ring. In pvcalls, they are unused. In xen
> > 9pfs, they are used to read or write the 9pfs header. In other protocols
> > they could be used to read/write the whole request structure. See
> > docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
> > is on the ring, and how to handle notifications.
> > 
> > There is a ring_size parameter to most functions so that protocols using
> > these macros don't have to have a statically defined ring order at build
> > time. In pvcalls for example, each new ring could have a different
> > order.
> > 
> > These macros don't help you share the indexes page or the event channels
> > needed for notifications. You can do that with other out of band
> > mechanisms, such as xenstore or another ring.
> > 
> > It is not possible to use a macro to define another macro with a
> > variable name. For this reason, this patch introduces static inline
> > functions instead, that are not C89 compliant. Additionally, the macro
> > defines a struct with a variable sized array, which is also not C89
> > compliant.
> > 
> > Signed-off-by: Stefano Stabellini <stefano@xxxxxxxxxxx>
> > CC: konrad.wilk@xxxxxxxxxx
> > 
> > ---
> > Changes in v4:
> > - remove packet_t, use void* and size instead
> 
> There seems to be quite a bit of lively discussion on the implementation
> part. Are there any changes to this file based on that discussion?

No changes, or requests for changes, to the macros so far. But I made
clear that these macros need to be accepted in xen.git first, before
they can be used elsewhere.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel