Re: [libvirt] [PATCH V2 1/5] Add public API virDomainSendSysrq
On 12/15/2014 11:51 PM, Chun Yan Liu wrote:
>
> I tried to define as 'char key', but meet some trouble in remote protocol,
> +struct remote_domain_send_sysrq_args {
> + remote_nonnull_domain dom;
> + char key;
> +};
> will report 'char key' as unsupported type.
Any ideas here?
For the remote protocol, either pass 'int key' (three bytes wasted on
the wire for the RPC call probably won't hurt, particularly since RPC
tends to pad out to multiples of 4 anyways)...
With 'char key' in remote_protocol.x, it'll report:
"unhandled type for argument value: char key; at ./rpc/gendispatch.pl line
1234."
I didn't find a way to avoid that, that's why I turned to use 'char *key'
(a string, and
when calling libxl API, pass key[0]).
...or you'll have to edit the guts of gendispatch.pl to teach it to
handle a 'char' type.
>
>> Moreover, wouldn't it be better to provide an
>> enum of possible values with meaningful names (rather than keys), such
>> as
>>
>> typedef enum {
>> VIR_DOMAIN_SYSRQ_REBOOT,
>> VIR_DOMAIN_SYSRQ_CRASH,
>> VIR_DOMAIN_SYSRQ_OOM_KILL,
>> VIR_DOMAIN_SYSRQ_SYNC,
>> ...
>> } virDomainSysrqCommand;
>>
>> This way, virDomainSendSysrq(dom, VIR_DOMAIN_SYSRQ_OOM_KILL, 0) would be
>> pretty self-explaining. The prototype would have to change to
This would be better, in which case you WANT 'int key' in the RPC
protocol (since we treat ALL enums as ints for ABI reasons).
>
> Mainly because xen/libxl API both accept letter as parameter directly, so
> define
> enum will need to map enum to letter before calling xen/libxl API.
Mapping from decent public API to under-the-hood API is one of the
reasons libvirt exists. I'd rather have a decent API with a nice enum,
rather than worrying about which magic char* values work for a
particular hypervisor.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 539 bytes)