On Mon, Aug 24, 2009 at 03:24:13PM -0400, Laine Stump wrote:
> (This probably seems like overanalysis of a simple problem. That's what
> I'm best at ;-)
>
> Due to oversight, the function virInterfaceLookupByMACString() can only
> return a single interface, but it's possible that a host may have more
> than one interface with the same MAC. Since the API had already been
> released by the time we realized this, the existing function will remain
> and a new one added that can return a list of interfaces. This new API
> will need to deal with the fact that the list length is effectively
> unbounded. I can see three ways of dealing with this, and want to learn
> which is preferred by others before spending time on the implementation.
>
>
> 1) The array containing the list is allocated by libvirt, freed by caller.
>
> int virInterfaceLookupAllByMACString(virConnectPtr conn, const
> char *mac, virInterfacePtr **matches);
>
> "matches" will point to an array of virInterfacePtr, and that
> array's length will be the return value. This array will be
> allocated by libvirt, but must be freed by the application when
> it's finished.
>
> Usage (ignoring errors, of course :-):
>
> virInterfacePtr *matches;
> int matchCt;
>
> matchCt = virInterfaceLookupAllByMACString(conn,
> "00:01:02:03:04:05", &matches);
> for (i = 0; i < matchCt; i++) {
> /* do something with an interface */
> virInterfaceFree(matches[i]);
> }
> free(matches);
[...]
> (3) is closest to behavior of other libvirt APIs, but requires more
> functions in the API, and could lead to situations where newly added
> interfaces aren't in the list (if a new interface is added between
> calling the Count function and the Lookup function) . (2) has a more
> compact API (one which matches the netcf API exactly), but has the same
> problems with potential bad counts. (1) seems like the cleanest API, but
> I don't know what others' opinions are on having libvirt allocate the
> array (since that's not how its done for other similar things, eg
> virConnectListInterface, virConnectListNetworks, etc), or maybe there's
> some limitation of the RPC I haven't considered that makes it unfeasible.
I would tend to prefer 1) at this point too, I don't see why 1) whould
be harder than 2 or 3 for RPCs or something, and in any case the
python bindings will have to be handcoded for any of the 3.
IMHO 2 and 3 both suffer a race condition where you call to get the
length and when you actually make the request another interface may have
been added in the meantime, even if interface activation is slow, we
should try to avoid this now IMHO.
The thing which is the hardest IMHO is properly describing and try to
make sure all client apps using any of the 3 apis will correctly call
virInterfaceFree() on each of the returned item of the array.
Maybe having the example in the function comment could help,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list