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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@aporeto.com>
> CC: konrad.wilk@oracle.com
> 
> ---
> 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?

Thanks.

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