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

Re: [Xen-devel] [PATCH] vm_event: Add a new opcode to get VM_EVENT_INTERFACE_VERSION



>>> On 13.02.19 at 17:36, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
> On Wed, 2019-02-13 at 08:27 -0700, Jan Beulich wrote:
>> > > > On 13.02.19 at 14:25, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
>> > @@ -843,7 +844,15 @@ struct xen_domctl_vm_event_op {
>> >      uint32_t       op;           /* XEN_VM_EVENT_* */
>> >      uint32_t       mode;         /* XEN_DOMCTL_VM_EVENT_OP_* */
>> >  
>> > -    uint32_t port;              /* OUT: event channel for ring */
>> > +    union {
>> > +        struct {
>> > +            uint32_t port;       /* OUT: event channel for ring */
>> > +        } enable;
>> > +
>> > +        struct {
>> > +            uint32_t value;
>> > +        } get_interface_version;
>> 
>> Why the wrapper structs? Having just a "port" and "version"
>> field inside the union would be good enough, wouldn't it? But
>> even if you want to stick to that, the new structure's name
>> could be simply "version", thus also allowing re-use for a
>> hypothetical "set-version" operation (in case multiple versions
>> would want/need to be supported going forward).
> I chose to wrap the "port" field in a structure because it's valid only
> for the XEN_VM_EVENT_ENABLE operation (I have used the wrapping structs
> in order to match the operation name). 

I guessed as much. But there's nothing preventing the field
for becoming applicable to some future sub-op.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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