On Wed, Jul 22, 2009 at 01:20:57AM -0400, Laine Stump wrote: > If the mac address of an interface is changed, we must either create a > new virInterface object in the cache that has the new name/mac, or > modify the existing object in the cache. Because the cache is in a > hash that's indexed by name only, we can't create a new entry having > the same name without destroying the old one first (which isn't a > possibility as someone else is already referencing the old one), so > we're stuck modifying the existing entry. We have to do that without > changing the pointer to the mac though, so we really can only do it if > the length of the new mac is equal to or less than the old > mac. Otherwise, we have to just bail. > > Fixing this problem to properly handle this corner case would require > a hash table that used both name and mac as keys, but that would be > inefficient (using the existing hash table implementation, which only > allows a single key), and probably unnecessary, as the length of mac > for any given interface will never change in practice. Yep, the odds of this error case happening are sooooo small, that giving a fatal error here is more than good enough. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list