[PATCH] route/link: handle RTEXT_FILTER_BRVLAN_COMPRESSED

[Tobias Jungel]

On Do, 2015-11-26 at 06:28 -0700, David Ahern wrote:
> Thanks for working on this.
> 
> On 11/26/15 3:06 AM, Tobias Jungel wrote:
> > notifications from the kernel regarding vlan ids are now handled
> > 
> > Signed-off-by: Tobias Jungel <tobias.jungel at bisdn.de>
> > ---
> >   lib/route/link/bridge.c | 30 +++++++++++++++++++++++-------
> >   1 file changed, 23 insertions(+), 7 deletions(-)
> > 
> > diff --git a/lib/route/link/bridge.c b/lib/route/link/bridge.c
> > index 9510fde..e40f890 100644
> > --- a/lib/route/link/bridge.c
> > +++ b/lib/route/link/bridge.c
> > @@ -190,6 +190,8 @@ static int bridge_parse_af(struct rtnl_link
> > *link, struct nlattr *attr,
> >   {
> >   	struct bridge_data *bd = data;
> >   	struct bridge_vlan_info *vinfo = NULL;
> > +	static uint16_t vid_range_start = 0;
> > +	static uint16_t vid_range_flags = -1;
> 
> The use of static here is a bit scary; there is no guarantee that 
> successive calls to bridge_parse_af are from the parsing of the same 
> message.

Yes, that's true. On the other hand this would imply the kernel is
sending wrong messages. Still  it's a valid point.

> 
> I think this requires an alternative parse_af handler (eg., 
> parse_af_full) that is passed the full nested attribute.
> 

Yes, that's what I had done in my original patch. So we would call
either parse_af or parse_af_full depending which one is existing?

If this assumption is fine I can give it a try.

> Alternatively, though much more complex, is to pass private data that
> can be used to store data between calls to parse_af handler. This
> would 
> also require a fini handler to verify full parsing (e.g., both start
> and 
> end attributes were seen). Former seems much simpler.

Agree.

> 
> David