Date: Sat, 21 Dec 2002 10:11:27 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: Sergey Mokryshev <mokr@mokr.net>, Vallo Kallaste <kalts@estpak.ee>, Sam Leffler <sam@errno.com>, Hiten Pandya <hiten@unixdaemons.com>, current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 Message-ID: <3E04AECF.F7D62C7C@mindspring.com> References: <200212210452.PAA21280@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed wrote:
> > 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.
The original posting in this thread gave a patch to unconditionalize
the PFIL_HOOKS thing, so that the ipfilter module could load on a
default kernel, without having to do a reasonable amount of work.
The initial reason claimed for doing this was to avoid the error
message about unresolved symbols, when trying to load the ipfilter
module. In other words, it was a complaint that the messages were
not specific to the problem, but were rather the generic messages.
My response to that was that you could create accessor/mutator
functions which were always defined, but not always functional.
By using these functions, instead of trying to access the pointers
directly, there are no undefined symbols, and you get the specific
error message, rather than the generic: any message you want it to
print.
But the complaint was just an ecuse. The real reason is that the
people complaining don't want to have to recompile the kernel to
use the ipfilter module: the complaint was because they wanted it
to be resolved in a particular way, so that they got a result that
they weren't willing to ask for directly. Solving the first one
left them unhappy.
That's fine; now that the truth has come out, instead of being
coyly hidden in a side issue, it's obvious what's wanted.
But compiling the kernel with the hooks in place is not the only
way to solve the problem.
Things would be a lot easier if people would ask for what they
want, instead of trying to out-strategize the people they expect
to say "no", if they were to ask for what they really wanted. 8-(.
> 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.
Yeah, that's the reason that BPF and netgraph and streams and ...
were invented, too. Wouldn't it be great if everyone adopted the
API I like best? 8-) 8-).
> > 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.
That's not a good demand; here's why: There are two types of
data paths: (1) the fast path, and (2) the path for research and
for things that are going to be slow anyway, by their nature.
The ipfilter code is in the second category.
It's really bogus to insist that everything take the slow path
because something slow has to take the slow path.
-- Terry
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?3E04AECF.F7D62C7C>