On Sunday 2008-10-05 08:34, Patrick McHardy wrote:
> We've talked about reorganizing net/netfilter in a smaller group
> during the workshop. Its currently quite crowded in there,
> additionally the IPVS guys are moving their code under
> net/netfilter/ipvs in 2.6.28.
>
> 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.)
> parts of this structure would be mirrored in net/ipv4/netfilter
> and net/ipv6/netfilter:
>
> net/netfilter/xtables/matches
> net/netfilter/xtables/targets
> net/netfilter/ct/protocols
> net/netfilter/ct/helpers
>
> I'm not sure whether this is too much since 4 directory
> levels seem a bit extreme.
If you take that structure _and_ mirror it in ipv4, you get:
net/ipv4/netfilter/xtables/matches/ which is already 5 :-)
> 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.
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?
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?
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
