DragonFly kernel List (threaded) for 2011-01
Re: Time to let go of ipfilter
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: 1295699533 crater_reader.dragonflybsd.org 886 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14843
On 1/22/2011 10:04, Edward O'Callaghan wrote:
> I agree, however I have no doubt it will be added soon since this is
> also a limitation for NetBSD usage of NPF as well.. more my point, +1
> to EOL'ing older solutions that are no longer maintained or scalable.
> One of the things that I myself consider a 'feature' of Dragonfly is
> less old junk running in kernel space (both important on a security
> and stability stand point) and a less bulky userland.
Nothing is bulkier because of ipf or any other non-pf filter, since you
will get it only if you specified it in your config, and it isn't the
We really shouldn't argue from some simplifying black and white "new ==
good, old == bad" standpoint here.
Apparently Joris has his reasons to use ipf and we have to see if pf (or
ipfw2) cuts it for his setup. Likewise, others are still using ipfw2 for
one technical reason or the other. See what Matt pointed out, for one,
and I've also heard that it's faster (from other people).
I'm not saying we must keep ipf (and I'd rather say not), but the
decision whether to keep it or nuke it should not be made based upon its
age (at least as long as it works, which apparently it does), but rather
upon whether pf is suitable for these scenarios instead.