On 09/23/2014 12:46 PM, Pavel Hrdina wrote:
> This new event will use typedParameters to expose what has been actually
> updated and the reason is that we can in the future extend any tunable
> values or add new tunable values. With typedParameters we don't have to
> worry about creating some other events, we will just use this universal
> event to inform user about updates.
>
> Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>
> ---
>
When the event is issued, does it contain ONLY parameters for what just
changed, or does it list ALL tunables including the unchanged ones?
It feels like your API is only capable of listing the new tunable value.
Is anyone using this event going to want to know both former and new
value at the same time?
>
> +/**
> + * virConnectDomainEventTunableCallback:
> + * @conn: connection object
> + * @dom: domain on which the event occurred
> + * @params: changed tunable values stored as array of virTypedParameter
> + * @nparams: size of the array
> + * @opaque: application specified data
> + *
> + * This callback occurs when tunable values are updated. The params must not
> + * be freed in the callback handler as it's done internally after the callback
> + * handler is executed.
> + *
> + * The callback signature to use when registering for an event of type
> + * VIR_DOMAIN_EVENT_ID_TUNABLE with virConnectDomainEventRegisterAny()
> + */
> +typedef void (*virConnectDomainEventTunableCallback)(virConnectPtr conn,
> + virDomainPtr dom,
> + virTypedParameterPtr params,
> + int nparams,
> + void *opaque);
Where do we document what names of tunables to expect?
> +++ b/daemon/remote.c
> +static int
> +remoteRelayDomainEventTunable(virConnectPtr conn,
> + virDomainPtr dom,
> + virTypedParameterPtr params,
> + int nparams,
> + void *opaque)
> +{
> + daemonClientEventCallbackPtr callback = opaque;
> + remote_domain_event_callback_tunable_msg data;
> +
> + if (callback->callbackID < 0 ||
> + !remoteRelayDomainEventCheckACL(callback->client, conn, dom))
> + return -1;
> +
> + VIR_DEBUG("Relaying domain tunable event %s %d, callback %d",
> + dom->name, dom->id, callback->callbackID);
> +
Might also be nice to log "%p %n", params, nparams
> +++ b/src/remote/remote_protocol.x
> @@ -247,6 +247,9 @@ const REMOTE_NETWORK_DHCP_LEASES_MAX = 65536;
> /* Upper limit on count of parameters returned via bulk stats API */
> const REMOTE_CONNECT_GET_ALL_DOMAIN_STATS_MAX = 4096;
>
> +/* Upper limit of message size for tunable event. */
> +const REMOTE_DOMAIN_EVENT_TUNABLE_MAX = 8388608;
That feels excessive...
> +
> /* UUID. VIR_UUID_BUFLEN definition comes from libvirt.h */
> typedef opaque remote_uuid[VIR_UUID_BUFLEN];
>
> @@ -2990,6 +2993,12 @@ struct remote_domain_event_block_job_2_msg {
> int status;
> };
>
> +struct remote_domain_event_callback_tunable_msg {
> + int callbackID;
> + remote_nonnull_domain dom;
> + remote_typed_param params<REMOTE_DOMAIN_EVENT_TUNABLE_MAX>;
...each param in the array will occupy multiple bytes. I think that
something as low as 2048 for REMOTE_DOMAIN_EVENT_TUNABLE_MAX is still
plenty (we don't have that many tunables yet); even if each tunable
requires 64 bytes to transmit (mostly in the name of the parameter, but
also in the type and value), that's still well under a megabyte limit of
information passed on an instance of the event.
The code looks okay, but I'm still a bit worried about the design.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list