Re: libiptc, arptables, ebtables plans or so - and header files

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> Hi Patrick and list,
> 
> 
> when Adam sent his xt_LED, I noticed that he avoided to create an 
> xt_LED.h and instead had the definition of the blob structs directly in 
> xt_LED.c and libxt_LED.c. It occurred to me that this has some 
> implications.
> 
> Theoretically, we could kill all {ipt,ip6t,xt}_*.h files in 
> <kernel>/include/linux/netfilter*/ -- since userspace, usually only 
> iptables, does not make use of them anyway, but has its own copies.
> 
> Yes, for simplicity, we let unifdef run over these headers before 
> copying them, but then again, when was the last time you had __KERNEL__ 
> in xt_*.h?
> 
> I really doubt there are any other userspace programs of these 
> files at this time. As I see it, these header files make only sense 
> when you are crafting blobs when interacting with libiptc. I am not 
> aware of any program making such extensive use of libiptc, probably due 
> to libiptc having been very closely kept in the iptables garden.
> 
> I would be tempted to suggest their removal from 
> <kernel>/include/linux/ and moving them into the code.
> 
> However... realistically you would need those files if you ever wanted 
> to interpret the blob when dealing with iptc.
> 
> Giving this some consideration, perhaps these header files should be 
> made available through iptables/a separate libiptc(-devel) package 
> instead of the kernel.

About moving the definitions - I don't see what this would buy us.
Besides that, the kernel defines these structures, so they really
belong there.

> All these philosophical questions lead to the question what should be 
> done about libiptc itself. It only looks bad because of the macro 
> substitution that is applied to produce a libip6tc... and this sort of 
> thing cannot really be resolved I figured. As in, using VFT tables to 
> dispatch for a given NFPROTO to get rid of the macro constructs is not 
> going to buy us anything - the code is so identical, it's really because 
> of miniscule differences between struct ipt_{internal_stuff} and struct 
> ip6t_{internal_stuff} that seem to make this an impossible undertaking. 
> Is it actually worth working on it?

Without having looked at it in much detail, I think it should
be pretty easy to define per-family functions to fill the
ipt_entry/ip6t_entry structs and a struct to describe the
length and offset differences. The remaining parts are invariant
across families, so the code should be easily unifiable.

> I have stopped my efforts to push arptables into iptables because 
> eventually I would have come to think about getting libiptc and libarptc 
> together, and I practically just did that with iptc and ip6tc (see 
> previous paragraph). Yeah I see it's SNAFU.
> 
> Possible exit? Clone iptables/libiptc/sonstwastables yet again into — 
> this time — an nfproto-agnostic table structure, but keep most other 
> pieces. No sample code yet, because I usually try to ask before going on 
> tasks like these.
> 
> Comments?

I think the best way is to abstract the very minor differences
using an af-specific callback for *_entry and some length information.
But I'm not familiar with libarptc, so this might not be enough.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html