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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Feb 09, 2017 at 05:31:46PM -0800, Stefano Stabellini wrote:
> 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?

Yeah. Padding makes me sleep easy at night :-)

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