[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 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).

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