[libvirt] [PATCHv2 1/4] util: introduce 2 new helpers for get interface IPv6 address

Luyao Huang lhuang at redhat.com
Wed Mar 11 15:11:00 UTC 2015


On 03/10/2015 06:50 PM, John Ferlan wrote:
>
> 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?

Oh, got it, i don't want to use it for decide use which address in those 
addresses, i just want to move the check and chose in the function which 
call it (virNetDevGetOneIPAddress()). Also if other people need a 
function to get all the address for one interface in the future, then 
virNetDevGetIfaddrsAddress() will help him (although i can not find a 
place need this until now :-( ).

>> 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...

As you said, if we want to get a right address, we need more information 
from the user (address type...), and still need some (or a lot ) patches 
for this. However, I still think it won't work for every scene even we 
add a lot of filters and check, because we cannot know and control 
everything in the different env :)

So as Jan's advise, hooks can be a good choice in the different scene.
>
> John

Luyao




More information about the libvir-list mailing list