On 03/10/2015 06:03 AM, lhuang wrote:
<...snip...>
>> Interesting idea, but you'd be just throwing things away. I could
>> perhaps having some code "periodically" cache addresses... or cache
>> addresses, subscribe to some event to let you know when a new address is
>> generated so you can add it to your list (if there is one)...
>>
>> But, how do you use it?
>
> Sorry, i don't know what these words' ("how do you use it ?") mean.
>
My point was - how does the existing code decide which of the 'n'
addresses found/returned to use as "the" address?
> I guess your mean is ask me how to use the code or function you
> mentioned, i think maybe
> we can avoid to use it :)
>
> However this should be another patch which add a function to get a list
> of ip address.
>
Sure, but would it be just for display purposes only? Once there is more
than one address per dev_name being queried, code that wants to use "an"
address will need to have some decision point in order to "filter" out
addresses known to be bad. Perhaps this is done by type - multicast,
localnet, etc or perhaps by some other lookup mechanism. I'm thinking of
the netinet/in.h macros (search on MULTICAST, LOCAL, LOOPBACK, etc.).
Whatever "filters" are desired, they could be added as an attribute list
of sorts (eg, filter='multicast,local') that way it's up to the consumer
to decide which filters apply knowing what that filter maps to. In the
example you provided ("2001:db8:ca2:2::1/64") - what about that address
made it unusable? That's what needs to be filtered... Doing a google
search on the address ironically points a bz that Laine owns... I'm not
"up" on all the IPv6 addressing rules, so my view is a more high level...
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list