Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel registration interface

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Feb 28, 2013 at 11:32:24AM +0000, Jan Beulich wrote:
> >>> On 28.02.13 at 12:25, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > On Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> > +/* commands:
> >> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel 
> >> > types,
> >> > + *                _NONE      supported types are or'ed in return value 
> >> > of
> >> > + *                           the hypercall.
> >> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> >> > + */
> >> > +#define EVTCHN_EXTENDED_QUERY 0
> >> > +/* supported extended event channel */
> >> > +#define EVTCHN_EXTENDED_NONE  0
> >> > +#define _EVTCHN_EXTENDED_L3   0
> >> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> >> > +struct evtchn_register_extended {
> >> > +    /* IN parameters. */
> >> > +    uint32_t cmd;
> >> 
> >> Looking at patch 18 you seem to indeed plan on passing a bit mask
> >> with a single bit set as command. Is that really reasonable? I can
> >> see the need for the query to return a bit mask, but that's it.
> >> 
> > 
> > When passing as command, the cmd field is not a bit mask. It is just
> > that I reuse the numeric representation of the bit mask, saving the need
> > to assign different numbers to commands.
> 
> I understand that, but this will limit you to 32 commands (plus
> zero for the query).
> 
> I'd instead suggest to set _EVTCHN_EXTENDED_L3 to 1, and
> pass this as command. Bit 0 of the mask returned by the query
> will then remain unused, allowing it to become a meaning when
> e.g. the 31 bits don't suffice anymore. Which isn't to say that
> I expect 31 or even more different implementations here - I
> merely like to have interfaces be extensible from an abstract
> perspective, even if one can't foresee the need for extensions
> (which might turn out necessary tens of years later).
> 

Sounds reasonable, I'll make it that way.


Wei.

> Jan
> 

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