On 26/11/10 14:59, 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. > > That does not sound like a showstopper, though. > >>>> 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. >> >> Great, this approach requires more memory because you spend one netlink >> header for every rule, but the cost is worth since it provides flexibility. > > As far as I can see, it won't cost me more memory; char buf[MNL_BUFFER_SIZE] > remains, and the kernel part does not have to keep more state than before > anyway, so it's a zero-sum game. I meant that less rule-set data will fit into one buffer, but that extra memory consumption gives you flexibility comes in return. >>> On the other extreme, Perl5 has shown that, when there is no full >>> specification, the code fills in. As it stands, af_netlink.c does >>> support attribute ordering :-) >> >> I agree, it would be great to have some more specifications. However, 1) >> someone would have to like doing that, and 2) Linux kernel evolves so >> quick that documenting aspects remains a daunting task. Anyway, I don't >> throw the towel on documentation, actually I'd like to do that. >> >> You are quite prolific in writing documentation, let me know if you are >> interested if I write some drafts, in case that you want to >> contribute/review. Or let me know if you decide to write something, I'd >> be pleased to contribute of course. > > I have in the pipeline an Netlink e-book, though it's more of a large > howto (like "Writing Netfilter Modules") than an academicly dry RFC. I have a 25 pages document that looks like a HOWTO for libmnl and Netlink sockets in general that I'll release soon. I didn't publish it yet because I wanted to release the library first. It comes after my article. But you are free not to cooperate and do the "lone rider" thing, of course. >>> [...] memory needs to be allocated and stored, right before >>> netlink_dump_start is called. [But] because nlk->cb->cb_args is >>> inaccessible from outside[...], the lookup and allocation is >>> currently done inside the dump function[...] >> >> What is that initial data handling in dumps for? > > Making an atomic snapshot/copy of the table. A userspace client > could take almost indefinitely on retrieving a table, so it is > possible that something else changes tables meanwhile. Why don't you lock the table during the dump? -- 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
