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>