Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and Citrix blkif multi-page ring extensions

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
> >> @@ -187,6 +216,25 @@
> >>  *      The machine ABI rules governing the format of all ring request and
> >>  *      response structures.
> >>  *
> >> + * ring-page-order
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  0
> >> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> > 
> > Why not just max-ring-page-order. After all, the value is meaningless
> > for a backend that only exposes max-ring-pages.
> > 
> >> + *      Notes:          1, 3
> >> + *
> >> + *      The size of the frontend allocated request ring buffer in units
> >> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 
> >> pages,
> >> + *      etc.).
> >> + *
> >> + * ring-pages
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  1
> >> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> > 
> > Similarly here - just max-ring-pages should do.
> 
> This patch documents existing extensions.  For a new driver to properly 
> negotiate a
> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
> (ring-page-order),
> you must use the XenBus node names as I've defined them here.

Can we pick one and mark it as preferred and the other deprecated or
similar? Perhaps backends will have to support both for the foreseeable
future but we should make it possible for frontends to just pick one if
that's what they want while nudging them in the direction of all picking
the same one.

I think the decision should made by the current state of mainline Linux
& BSD front and backends, i.e. we should prefer what has been upstreamed
rather than private forks if possible. Does anyone know what that state
is?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel