[PATCH] route/link: handle RTEXT_FILTER_BRVLAN_COMPRESSED

[Tobias Jungel]

On Do, 2015-11-26 at 07:37 -0700, David Ahern wrote:
> On 11/26/15 7:24 AM, 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?
> 
> 
> good point. Overload ao_parse_af? For AF_BRIDGE just pass the full 
> attribute.
> 

I don't have a strong opinion on this. Having the _full call seems a
bit cleaner API though, but comes with the above mentioned drawback.
Since the function is called only internally and only from
link_msg_parser I guess its fine either way.