On 05.07.2013 20:38, Cy Schubert wrote:
In message <20130705084649.gc67...@freebsd.org>, Gleb Smirnoff writes:
What I'd prefer to see is the following:

- commit new ipfilter untouched to vendor-sys/ipfilter
- nuke sys/contrib/ipfilter
- svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter

Having ipfilter in one place instead of two (vendor and vendor-sys) makes a
lot more sense.

I suppose we could put ipfilter's kernel components in sys/netpfil but what
about the userland sources? Also see my reply below regarding keeping it in
contrib.


In future imports do:

- commit newer ipfilter to vendor-sys/ipfilter
- svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter

What's the reason to keep code in contrib?

The reason to keep ipftilter in contrib is to maintain consistency with
other contributed software such as bind, nvi, sendmail, pf, and a host of
other notable software we don't maintain ourselves. Maintaining consistency
with other contributed software should probably be maintained. I'm open to
moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as
long as consistency is maintained across the board.

Do you think we should put the userland sources also in the same location
or should we maintain a similar separation we do today? I'm open to both
however I'd prefer keeping all vendor software (kernel and userland) in one
location.

I think the main distinction here is whether the adaptions to
FreeBSD are kept local (resulting in almost a fork) or are fed
upstream so that successive updates require less or no local
changes.

Having the kernel part in sys/netpfil certainly makes it easier
for kernel people to adjust it to changed realities.

IIRC ipfilter also has very messy ifdef's all over the place for
every possible ancient version of FreeBSD.  This probably should
be cleaned up (and upstreamed) as well.

--
Andre

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to