Jan Engelhardt wrote:
On Sunday 2008-10-05 08:34, Patrick McHardy wrote:
Some suggestions for a new directory structure:
net/netfilter/xtables
net/netfilter/{ct, conntrack, nfct, ...}
net/netfilter/nftables for my new stuff
Yes definitely welcomed.
We could go further by splitting up xtables and conntrack,
That's just what you proposed! Or at least that is what I think of
Netfilter. Xtables and Conntrack are already separated, simply
because each one can be used without the other. (Minus things like
xt_conntrack, which I think belong to Xtables.)
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.
Since the amount of core code is increasing too, one more
thought was
net/netfilter/core
containing core.c, netfilter.c, logging and queuing stuff and
everything netlink related that doesn't fall in a more specific
area.
I think the core stuff can remain in net/netfilter/. Not because
it is growing, but because other subsystems do just that.
Like, there is fs/ (with the core code) and fs/<component>/ for
anything not-so-core-y.
I agree that its more logical to keep the core stuff at the
netfilter root.
What I really certainly would like to see is that we somehow get rid
of the oddness of naming L3 trackers and L4 trackers. Right now we
have (two examples)
-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.
One thing I have done in my git realms is just call my branches
"nfct_foo" simply because I was too lazy to type "nf_conntrack_foo".
Maybe we could do the same for our files? Maybe we can even get rid
of the nf_conntrack_/nfct_ prefix at all when they are moved into
net/netfilter/conntrack/, but still have it in their .ko files. IOW:
net/netfilter/conntrack/ftp.c produces
net/netfilter/conntrack/nfct_ftp.ko. How about it?
Its a quite verbose naming scheme currently, I agree. I like
some common prefixes for related things, even if slightly
redundant, but using nfct_ instead of nf_conntrack_ sounds
fine to me.
core.c (remains)
nf_conntrack_acct.c -> conntrack/acct.c
nf_conntrack_amanda.c -> conntrack/amanda.c
nf_conntrack_core.c -> conntrack/core.c
...
nf_log.c (remains)
nfnetlink.c (remains)
nfnetlink_log.c (remains)
nfnetlink_queue.c (...)
nf_queue.c
nf_sockopt.c
x_tables.c -> xtables/x_tables.c
xt_CLASSIFY.c -> xtables/CLASSIFY.c (or just keep xt_ prefix?)
xt_comment.c -> ...
--
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
