Date: Sat, 21 Dec 2002 15:52:51 +1100 From: Darren Reed <darrenr@reed.wattle.id.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Sergey Mokryshev <mokr@mokr.net>, Vallo Kallaste <kalts@estpak.ee>, Sam Leffler <sam@errno.com>, Hiten Pandya <hiten@unixdaemons.com>, Darren Reed <darrenr@reed.wattle.id.au>, current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 Message-ID: <200212210452.PAA21280@avalon.reed.wattle.id.au> In-Reply-To: <3E03BC72.422C971F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In some email I received from Terry Lambert, sie wrote:
> Sergey Mokryshev wrote:
> > Unfortunately nobody cares to look into PR database (conf/44576)
> >
> > In case PFIL_HOOKS really slows IP processing I don't mind keeping this
> > out of GENERIC, however it should be noted in UPDATING and release notes.
> >
> > I did not do any time consuming searches the first time I tried to load
> > ipl.ko, but I've spent some time reading NOTES before upgrading to
> > -CURRENT and I am using IP Filter for about three years now on Solaris
> > and FreeBSD (thanks, Darren).
> >
> > IMHO GENERIC is not supposed to be fast, but to be useable out-of-the box.
>
> This is a reasonable argument... if it's possible to tune it so
> that it's fast. Hacking in the IP Filter hooks unonditionally
> for code that can't really be distributed as part of the system
> because of its license, and thus making things slower, with no
> chance to make them faster later, is not my idea of A Really
> Good Thing(tm).
I don't understand this paragraph at all.
pfil(9) comes from NetBSD. It's not quite upto date with the
NetBSD code because I'm waiting for them to sort out how to deal
with bridging before updating again.
The purpose of pfil(9) is not to facilitate ipfilter but to act
as a mechanism for anything to filter packets to use it as the
way to receive packets. Ideally ipfw* should also use pfil(9)
and not have those large chunks of code in ip_{in,out}put.c.
> Probably the correct thing to do is to wire in ipfilter as a
> Netgraph module.
If/when the joining between layer 2 and layer 3 in the kernel
uses netgraph rather than the current mechanisms, then it would
be appropriate to use netgraph for ipfilter.
Darren
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212210452.PAA21280>