libnl3 ... missing feature for retrieving cached address objects?

[Thomas Graf]

On 09/09/13 at 08:25pm, David Sommerseth wrote:
> On 09/09/13 17:57, David Sommerseth wrote:
> > 
> > Hi,
> > 
> > I'm doing some massive updates to python-ethtool, which uses libnl to
> > retrieve information about network and hardware configurations.  The use
> > of libnl-1 was added quite a long time ago to especially implement IPv6
> > support.  I'm now doing a lot of changes to improve the overall code and
> > simplify the implementation.
> > 
> > In this process, I found rtnl_addr_get() too specific, as I want to
> > retrieve the IP address for a specific link.  From what I could see,
> > rtnl_addr_get() will always filter based on the struct nl_address object
> > passed to it and match against the given address.  This is too strict
> > for my use case.  Further I couldn't find any other obvious solutions to
> > extract this information, except traversing all objects using
> > nl_cache_foreach_filter() and a callback function.
> > 
> > So I propose a new function - rtnl_addr_get_index() (patch attached)
> > which is a simplified rtnl_addr_get() function.  On my slight testing,
> > this seems to work quite well.
> > 
> > However, I'm not sure if I'm overlooking something here?  Or is there a
> > better or simpler approach?
> 
> Okay, I was obviously too quick on my testing.  This approach doesn't
> fully resolve my challenge.  I just discovered links with multiple IP
> addresses will not retrieve all IP addresses with the approach the patch
> introduces.
> 
> The solutions seems to be to use rtnl_addr_set_ifindex() on an otherwise
> "empty" rtnl_addr object together with nl_cache_foreach_filter() and a
> callback function.
> 
> If anyone have an easier approach, I'm all ears.

Use of a filter object is what I would recommend to use in this case
as well. Customized lookup functions are only added for frequently
used lookup keys and if the key explicitly maps to a single object.

So instead of constructing lists and returning them we expose the
traversal function but it would be absolutely doable to provide a
generic list construction function that could be passed to the
iterator and that would return a list instead of calling a callback.