Julius Volz wrote:
quoted text
> On Mon, Jun 16, 2008 at 1:47 PM, Patrick McHardy <kaber@trash.net> wrote:
>>> Option c) looks reasonable to me and also seems easy to handle in
>>> general. Is this the way to go? Or do we want the interface to look
>>> completely different this time?
>> b) or c) both look fine.
> 
> A couple of other Netlink questions came up while reading some code:
> 
> 1) There are many examples of the following two cases in the kernel:
> 
> nla_nest_start(skb, SOME_ATTR_TYPE | NLA_F_NESTED);
> nla_nest_start(skb, SOME_ATTR_TYPE);
> 
> Why don't all cases have NLA_F_NESTED? Then again, this bit is never
> ever read out again (at least not in the kernel), so I guess people
> are just using their implicit knowledge that a specific attribute type
> is always nested and never check the bit?
>
> Btw., couldn't we change nla_nest_start() to always add NLA_F_NESTED
> to the type?

The NLA_F_NESTED bit originated in nfnetlink, but was moved
to netlink so the new netlink parsing helpers could also be
used for nfnetlink. It can't be added to existing attributes
since userspace needs to mask it out again to get the real
attribute value and the non-nfnetlink userspace code doesn't
expect it.

quoted text
> 2) To send an array of attributes of the same type, you just add them
> serially? I was just confused at first that nla_parse() will save only
> one attribute of each type (the last one) in the destination array, so
> when dealing with arrays, it doesn't help. So I just iterate over the
> array with nla_for_each_attr() and parse each element manually, right?

Exactly, net/8021q/vlan_netlink.c has two examples of this (the
QoS mapping attributes).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html