[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.


Wei.

> Jan
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.