From owner-freebsd-hackers Sat Jun 19 7:36:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id F082E14E18; Sat, 19 Jun 1999 07:36:52 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id PAA81197; Sat, 19 Jun 1999 15:37:26 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 19 Jun 1999 15:37:26 +0100 (BST) From: Doug Rabson To: "Brian F. Feldman" Cc: Dag-Erling Smorgrav , Ruslan Ermilov , ugen@xonix.com, hackers@FreeBSD.org, luigi@FreeBSD.org Subject: Re: Introduction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 19 Jun 1999, Brian F. Feldman wrote: > On Sat, 19 Jun 1999, Doug Rabson wrote: > > > On 19 Jun 1999, Dag-Erling Smorgrav wrote: > > > > > Ruslan Ermilov writes: > > > > * Clean the existing code (both userland and kernel) (10-20% done) > > > > * Re-design the ipfw's API > > > > * Port the existing functionality to the new API > > > > * Proceed with new features > > > > > > Pretty please with sugar on top, design an API that can be extended > > > without breaking binary compatibility. We've had too much of that for > > > no good reason (at least once between 2.2.7 and 2.2.8, and once > > > between 3.1 and 3.2). > > > > As far as possible, all new apis in the kernel should be designed with a > > stable ABI. Its pretty simple if you follow a few simple rules: > > > > 1. Hide implementation data structures. Access all information > > outside the core implementation using function calls. > > 2. Try to avoid using complex structures in the api. Each > > structure in an api defines part of its ABI. Changing that > > structure later breaks the ABI. > > 3. Keep the external api as simple as possible. As a rule of > > thumb, try to write manpages for each function. If you can't > > describe the function accurately and concisely in a manpage > > then its too complex. > > > > It might be worth (discussion of) making ipfilter the firewall of > choice for 4.0. There would of course be rule conversion > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to a > KLD, cruft removed (I'm going to work on these), and ipfilter KLD > support (currently options IPFILTER_LKM) made a non-option. It seems > that our pretty proprietary ipfw is no longer a good idea. > And if Luigi ported all of his stuff to ipfilter from ipfw, and I > did per-[ug]id support for ipfilter (which I will), we'll definitely > be ahead. Ipfilter is a win for compatibilty/ubiquity, and seems to be > faster than ipfw anyway. Are there any technical arguments against > ipfilter or for ipfw? Note that: political arguments do not count, a > conversion method will be available for ipfw users, and we should have > anything special (DummyNet, uid/gid-based filtering) ported over to > ipfilter. I don't have a position on ipfw vs. ipfilter. As long as no functionality is lost, I don't see any problems changing. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message