On 03/12/10 22:03, Jan Engelhardt wrote:
On Friday 2010-11-26 09:25, Pablo Neira Ayuso wrote:
In fact, why don't we just use genetlink for new code instead?
Genetlink is similar. The main difference is that the ID family number
and multicast groups for each subsystem is not fixed, it's registered in
runtime. This means that you have to make the "family name resolution",
ie. to send a message to resolve the ID family number and multicast
groups before doing any operation.
Another reason is consistency, it's a good idea to use the mechanism
that other netfilter subsystems already use.
"Look, iptables uses ioctl! Let's use ioctl again for xt2."
It's up to you to use an interface from the stone age.
I am skeptical about shrinkfitting something onto an older
interface (nfnetlink) when there is genetlink..
That's an empty argument. Tell me one feature that nfnetlink does not
have have but genetlink does.
BTW, I didn't look at your protocol in deep yet but I'd suggest the
following basis to rework it: one netlink message, one rule operation.
I can agree with that suggestion, so I will be doing that.
Something else that came to mind -- if ordering of nlattrs is not
guaranteed inside nlmsg, we could just pack all the data into a
single attribute and mark it binary, which means potential relays (if
nl ever gets that far!) won't reorder it.
that's an abuse of netlink.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
