[RFC PATCH 3/5] Add AF_BRIDGE object update support to link cache

[Roopa Prabhu]

On 11/5/12 7:06 AM, Thomas Graf wrote:
> On 11/05/12 at 05:37am, roopa at cumulusnetworks.com wrote:
>> From: roopa<roopa at cumulusnetworks.com>
>>
>> This patch implements the oo_update operation for link cache objects.
>> This implementation currently only handles objects of type AF_BRIDGE.
>>
>> It updates the existing link object with the attributes of the new
>> AF_BRIDGE link object
>>
>> Signed-off-by: Roopa Prabhu<roopa at cumulusnetworks.com>
>> Reviewed-by: Nolan Leake<nolan at cumulusnetworks.com>
>> Reviewed-by: Shrijeet Mukherjee<shm at cumulusnetworks.com>
>> Reviewed-by: Wilson Kok<wkok at cumulusnetworks.com>
>
> I think this code should be in lib/route/link/bridge.c if it is
> AF_BRIDGE specific. I realize the filter is currently in link.c
> as well but that has always been a hack.
>
> What about you have a link_update() that does:
>
> af_ops = rtnl_link_af_ops_lookup(src->l_family);
> if (af_ops&&  af_ops->ao_update)
> 	return af_ops->ao_update(...);
> else
> 	return -NLE_OPNOTSUPP;
>
> That would allow to neatly move this to bridge.c and allow for a
> simplified update process. I guess you wouldn't even have to
> free and realloc the bridge data but could just overwrite the port
> state and link attributes.
>

ok.., yes...adding update op to af_ops and moving some of the af_ops 
update to  link/bridge.c will be cleaner. Will do.

Note that I had proposed this as yet another way to get the bridge 
objects in the original link cache. Since we are agreeing on the first 
approach to support AF_BRIDGE, this link update becomes a nice way to 
update the existing objects. So I will work on getting the first set of 
changes in and then submit a separate patch to fix the updating of 
existing objects.

Thanks thomas.

> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl