Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Thomas Graf]

* Patrick McHardy <42C350A1.1030602@trash.net> 2005-06-30 03:53
> Thomas Graf wrote:
> > At some point we should introduce a "generic" attribute
> > architecture for all netlink families. The connector
> > stuff will need it as well, so maybe the time has come
> > to actually do it.
> 
> I agree, most of the macros are just copied without modification
> anyway. One more thing I would like to change is the excessive
> use of RTA_PUT with structures on the stack. Using __RTA_PUT
> and putting together these structures in-place would be much
> nicer. nfnetlink has copied this part of rtnetlink.

Good point, after all, I think structs have been used too often
and we now suffer from backwards compatbility issues. The
points likely to be argueable are things like trim responsibility
in the error handling, i.e. delegate it down to the function
which also created the header or trim on every level. Other than
that the whole thing should be pretty straight forward.

What do you think about naming it nlattr?

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Patrick McHardy]

Thomas Graf wrote:
> Good point, after all, I think structs have been used too often
> and we now suffer from backwards compatbility issues. The
> points likely to be argueable are things like trim responsibility
> in the error handling, i.e. delegate it down to the function
> which also created the header or trim on every level. Other than
> that the whole thing should be pretty straight forward.

I think for nested attributes error handling should happen on the
outer level. Just trimming on the inner level would leave a
half-finished nested attribute.

> What do you think about naming it nlattr?

Sounds good.

Regards
Patrick

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Thomas Graf]

* Patrick McHardy <42C3F35B.50805@trash.net> 2005-06-30 15:27
> Thomas Graf wrote:
> > Good point, after all, I think structs have been used too often
> > and we now suffer from backwards compatbility issues. The
> > points likely to be argueable are things like trim responsibility
> > in the error handling, i.e. delegate it down to the function
> > which also created the header or trim on every level. Other than
> > that the whole thing should be pretty straight forward.
> 
> I think for nested attributes error handling should happen on the
> outer level. Just trimming on the inner level would leave a
> half-finished nested attribute.

I can agree with this, the question that remains is: do we want
to trim in functions where no nesting is done at all? i.e. things
like the generic network statistics dumping interface.

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Patrick McHardy]

Thomas Graf wrote:
> * Patrick McHardy <42C3F35B.50805@trash.net> 2005-06-30 15:27
>
>>I think for nested attributes error handling should happen on the
>>outer level. Just trimming on the inner level would leave a
>>half-finished nested attribute.
> 
> I can agree with this, the question that remains is: do we want
> to trim in functions where no nesting is done at all? i.e. things
> like the generic network statistics dumping interface.

Trimming isn't required in this case since the length is know and
checked in advance. An error should still be propagated back of
course so potential outer levels can do trimming.

Regards
Patrick

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Thomas Graf]

* Patrick McHardy <42C46374.5000407@trash.net> 2005-06-30 23:26
> Thomas Graf wrote:
> > * Patrick McHardy <42C3F35B.50805@trash.net> 2005-06-30 15:27
> >
> >>I think for nested attributes error handling should happen on the
> >>outer level. Just trimming on the inner level would leave a
> >>half-finished nested attribute.
> > 
> > I can agree with this, the question that remains is: do we want
> > to trim in functions where no nesting is done at all? i.e. things
> > like the generic network statistics dumping interface.
> 
> Trimming isn't required in this case since the length is know and
> checked in advance. An error should still be propagated back of
> course so potential outer levels can do trimming.

This is only true if one attribute is added. What I really meant
is something like em_text_dump() in em_text.c. Assuming we rework
areas like this one in order to avoid structs on the stack, we'll
have a lot of such cases where we might hit the limit while not
really knowing about the start of the nested tlv.

Anyways, I think this is a minor issue and we can safely ignore it
and delegate the trimming responsibility to the underlying layer
which "started" the nested tlv.

The gnet_stats interface was a bad example since it doesn't have
such a case.

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[David S. Miller]

From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 30 Jun 2005 23:34:59 +0200

> This is only true if one attribute is added. What I really meant
> is something like em_text_dump() in em_text.c.

Speaking of em_text.c, when one loads ematch rules into that
module it does a printk().  I assume that's a thinko and should
be removed?

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[Thomas Graf]

* David S. Miller <20050630.144942.74731532.davem@davemloft.net> 2005-06-30 14:49
> From: Thomas Graf <tgraf@suug.ch>
> Date: Thu, 30 Jun 2005 23:34:59 +0200
> 
> > This is only true if one attribute is added. What I really meant
> > is something like em_text_dump() in em_text.c.
> 
> Speaking of em_text.c, when one loads ematch rules into that
> module it does a printk().  I assume that's a thinko and should
> be removed?

Yes, it's a debugging leftover but I'll keep it in until rc3 so if
problems appear I have some debugging information. Given that is acceptable.

Re: [PATCH 1/2] updates for [nf|ct]netlink and event API

[David S. Miller]

From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 1 Jul 2005 00:08:14 +0200

> Yes, it's a debugging leftover but I'll keep it in until rc3 so if
> problems appear I have some debugging information. Given that is acceptable.

No problem.