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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
