Re: Xtables2 Netlink spec

[Pablo Neira Ayuso <pablo@netfilter.org>]

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?