[PATCH] route/link: handle RTEXT_FILTER_BRVLAN_COMPRESSED

[Tobias Jungel]

On Do, 2015-11-26 at 15:24 +0100, Tobias Jungel wrote:
> On Do, 2015-11-26 at 07:20 -0700, David Ahern wrote:
> > On 11/26/15 6:47 AM, Tobias Jungel wrote:
> > > > 
> > > > 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.
> > 
> > In parse_af_spec_bridge(), this:
> > 
> > +	if (af_ops && af_ops->ao_parse_af) {
> > +		nla_for_each_nested(af_attr, attr, remaining) {
> > +			err = af_ops->ao_parse_af(link, af_attr,
> > af_data);
> > +			if (err < 0)
> > +				goto errout;
> > +		}
> > +	}
> > 
> > would become
> > 
> > +	if (af_ops && af_ops->ao_parse_af_full) {
> > +		err = af_ops->ao_parse_af_full(link, attr,
> > af_data);
> > +		if (err < 0)
> > +			goto errout;
> > +	}
> > 
> > and then the full handler does the for_each_nested and the
> > processing
> > you have in this patch.
> 
> sure, the question was more about if we should have
> both ao_parse_af_full and ao_parse_af. And if we allow both, what
> happens when both are specified in a module. But maybe the latter is
> too constructed?
> 

k, since those functions are only called from the link_msg_parser its
too constructed... I'll send an updated patch then.

> >