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

Roopa Prabhu roopa at cumulusnetworks.com
Mon Nov 5 10:41:03 EST 2012


On 11/5/12 7:02 AM, Thomas Graf wrote:
> 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?

ok this sounds good to me. thanks.



More information about the libnl mailing list