[RFC PATCH 1/5] Add support for AF_BRIDGE family in link cache

Thomas Graf tgraf at suug.ch
Mon Nov 5 10:02:30 EST 2012


On 11/05/12 at 06:24am, Roopa Prabhu wrote:
> >Alternatively we could add nl_cache_set_flags() and
> >nl_cache_unset_flags() to allow modifying the iterate groups feature.
> >
> >Example:
> >	nl_cache_set_flags(link_cache, NL_CACHE_AF_ITER);
> >	nl_cache_refill(sk, link_cache);
> 
> yes this is good too. This will give the user full control over the
> flag like you suggested.
> But, if the user really is interested in AF_BRIDGE objects, and if
> the flag is not on by default for the link cache, the refill in
> nl_cache_mngr_add will not contain AF_BRIDGE objects and user will
> need to call an additional refill with the flag to get the AF_BRIDGE
> objects.

I see what you are trying to do here but that will break applications.
Currently nl_cache_mngr_add(..., "route/link", ...) will not contain
bridge objects and we can't change this all of a sudden.

Setting NL_CACHE_AF_ITER after the cache has been filled for the first
time is somewhat ugly so we need to find a way to let the user set
the flag earlier on.

An option would be to have nl_cache_mngr_add_cache() which allows to
add an existing cache to the cache manager and thus allows to:

	nl_cache_alloc_name("route/link", &cache);
        nl_cache_set_flags(cache, NL_CACHE_AF_ITER);
        nl_cache_mngr_add_cache(mngr, cache, ...);

How does that sound?



More information about the libnl mailing list