[libvirt] [PATCH] startupPolicy: Change event argument
Eric Blake
eblake at redhat.com
Wed Oct 26 15:39:15 UTC 2011
On 10/26/2011 05:30 AM, Daniel P. Berrange wrote:
> The device aliases are not intended to be limited to just QEMU. The
> intention when adding device aliases was to have a standard way to
> uniquely refer to a particular device, no matter what type of device
> it is. Previously you had to use disk targets, net MAC addrs, serial
> port numbers, etc, etc, and some device types didn't even have any
> good unique attribute. With device alias, we have a way to provide
> a standard identifer for any type of device. While other drivers
> may not use this ability yet, there's nothing preventing them from
> doing so.
I guess I can live with devAlias on output, if there were an easy way to
map from target to devAlias, and also to map from devAlias to target.
Also, it would be nice if functions that take device names and/or device
paths on input could also be taught to take devAlias on input as another
synonym.
In particular, I'm thinking of my recent work in commits 88a993b and
89b6284, where I taught disk snapshots, block peek, and getBlockInfo to
all operate on target name or disk path as synonyms. Making those
functions also operate on device aliases, as well as making 'virsh
domblklist' capable of outputting the devAlias that corresponds to each
disk, will make it easier to go between any of the three namespaces
(where two are under the control of the xml).
But your argument that blk io error events already use devAlias is
pretty convincing. I guess even if we don't have full transparency
between the namespaces yet, that consistency argues that both
disk-related events should be using the same data. So I think the best
plan forward is for this patch to keep devAlias after all (it needs
documentation, but it reduces the number of other places to patch), and
then later add a patch (series) that makes it easier to convert between
aliases and target names.
--
Eric Blake eblake at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
More information about the libvir-list
mailing list