Re: [Xen-devel] [DOC v4] Xen transport for 9pfs
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@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC v4] Xen transport for 9pfs
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@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC v4] Xen transport for 9pfs
> ## 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?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
