Date: Thu, 23 Apr 1998 15:36:41 +0200 From: Eivind Eklund <eivind@yes.no> To: hackers@FreeBSD.ORG Subject: Re: changing ipfw interface (was Re: cvs commit: src/sys/netinet ip_fw.c) Message-ID: <19980423144259.57155@follo.net> In-Reply-To: <9804231217.AA01806@avalon.reed.wattle.id.au.>; from darrenr@reed.wattle.id.au on Thu, Apr 23, 1998 at 10:12:54PM %2B1000
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 23, 1998 at 10:12:54PM +1000, darrenr@reed.wattle.id.au wrote: > In some email I received from Eivind Eklund, sie wrote: > [...] > > Well, what do you think? > > To me, it seems that it is effectively duplicating the BPF code, I don't understand why you see this change as really related to BPF. This is _not_ in any way duplicating BPF - this is just another way of passing the IPFW rules over the userland/kernel boundary. You could of course do most pure filtering using BPF instead of having IPFW and ipfilter at all; I'd say that's a different discussion. > plus you'd have a much more flexible solution with BPF and less > "extra code" in the kernel. Depending on how generic you want the outlined interface to be. It can be kept at the 'least generic level' as it is now, or propagated upward to be a gate for interfaces for all programs presently dependent on kernel-only structures (ps et. al). > Of course, maybe you don't want to write an ipfw rule -> BPF > converter :) Actually, something like this is on my long-term TODO-list (but it is impossible to say when I'll get around to it - probably not before 3.0, at least). However, BPF is not a convenient form for modification, and there need to be an interface to make it possible to modify rule lists. The above proposal is to modify the rule lists, which can then be converted to whatever internal form is convenient for optimal rules-processing (and there are a lot of options here, as you certainly know). > Plus, it only solves half of the problem - structure size changing > but not capabilities. If you ever remove a capability, the filter > rules could be screwed. There is no way of addressing capability removal short of propagating them to the user when they apply, and letting the user handle them. This is what the proposed interface do. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980423144259.57155>