Jan Engelhardt wrote:
On Sunday 2008-10-05 10:02, Patrick McHardy wrote:
Yes, confusing wording. I meant splitting them up internally,
i.e. xtables => matches/targets etc, as described below. And
its only about the directory structure of course, how things
work together at runtime remains the same.
I would not want to split matches and targets. Yes I am aware that we
have these guys wanting to store it on case-ignorant filesystems, but
we would still have all the include files in a conflicting position.
net/netfilter/xtables/matches is already over my personal
preferred limit of 3. If at all, I think they should get
{pre|post}fixed à la tg_connmark.c (target) and mt_connmark.c (or
connmark_{tg,mt}.c, whichever makes 'em happy).
Yes, its probably going overboard in case of xtables. For conntrack
helpers and l4 protocols I'm not sure yet. I'll probably just give
it a try without the 4 levels and see how it turns out.
Also the idea of merging files for the benefit of reduces in-memory
size was floating. I have revisited the koredux branch since you said
on-disk size ain't important, so the exact _memory_ statistic is:
Well, not completely unimportant for some people, but its not
really my main concern since in those cases people tend not to
use modules anyway.
One extension per module:
Single blob:
Module Size Used by
xtables_ext 94312 0 (on-disk size 160K)
All blobs that xtables_ext encompasses:
Module Size Used by
[...]
total 165992 (on disk about 1037K)
That's a 43% reduction in memory.
Its a clear benefit, I don't doubt that. I mainly think this is not
netfilter specific at all and should be done on a kbuild level.
Linking all of them together also has some runtime impact because
of symbol dependencies, using let say tcpudp will probably pull
in (parts of) IPv6 and NAT. Having them grouped by dependencies
would avoid this.
-rw-r--r-- 1 15924 2008-09-09 20:34 nf_conntrack_ftp.c
-rw-r--r-- 1 43369 2008-09-09 20:33 nf_conntrack_proto_tcp.c
and in everybody's mind, FTP is a protocol too of course, “so why
does not ftp have a _proto part, and why does TCP?” one might ask.
We could just remove the _proto part (also helpful to reduce the
name length), as there is no clash between L3 and L4 trackers
except perhaps for proto_generic and l3proto_generic. Hm?
Agreed, this is a good opportunity to fix that as well.
The _proto prefix becomes redundant if we use
net/netfilter/ct/protocols
anyway.
It does not really solve anything IMHO. Protocols? FTP is one, so hm,
same confusion. This also got my anti-favorite 4-depth :)
Well, its not *that much* confusing since I believe most people are
aware of that part of the netfilter terminology. The main goal is
to get the directory contents to a more reasonable level and group
related stuff together; using just net/netfilter/ct is still a bit
too coarse in my opinion. Under that aspect, what would your proposed
structure be?
--
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
