|
Julius Volz wrote:
On Mon, Jun 16, 2008 at 1:47 PM, Patrick McHardy <kaber@xxxxxxxxx> 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.
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 lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
| 