Re: [Xen-devel] [DOC v4] Xen transport for 9pfs

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

On Wed, 8 Feb 2017, Konrad Rzeszutek Wilk wrote:
> > ## Ring Setup
> > 
> > The shared page has the following layout:
> > 
> >     typedef uint32_t XEN_9PFS_RING_IDX;
> > 
> >     struct xen_9pfs_intf {
> >             XEN_9PFS_RING_IDX in_cons, in_prod;
> >             uint8_t pad[56];
> >             XEN_9PFS_RING_IDX out_cons, out_prod;
> > 
> >             uint32_t ring_order;
> >         /* this is an array of (1 << ring_order) elements */
> >             grant_ref_t ref[1];
> >     };
> > 
> >     /* not actually C compliant (ring_order changes from ring to ring) */
> >     struct ring_data {
> >         char in[((1 << ring_order) << PAGE_SHIFT) / 2];
> >         char out[((1 << ring_order) << PAGE_SHIFT) / 2];
> >     };
> > 
> 
> This is the same comment about the the PV Calls structure.
> 
> Would it make sense to add the 'in_events' and 'out_events'
> as a notification mechanism?

As I wrote in the case of PV Calls, given that it's just an optimization
and increases complexity, what if we add some padding right after

  XEN_9PFS_RING_IDX out_cons, out_prod;

so that if we want to add it in the future, we can just place there,
instead of the first 4 bytes of the padding array?

    struct xen_9pfs_intf {
        XEN_9PFS_RING_IDX in_cons, in_prod;
        uint8_t pad[56];
        XEN_9PFS_RING_IDX out_cons, out_prod;
        uint8_t pad[56];

        uint32_t ring_order;
        /* this is an array of (1 << ring_order) elements */
        grant_ref_t ref[1];
    };


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