From owner-freebsd-hackers Sat Jun 19 7:24:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 02E2C14E18; Sat, 19 Jun 1999 07:24:08 -0700 (PDT) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA99863; Sat, 19 Jun 1999 10:23:48 -0400 (EDT) Date: Sat, 19 Jun 1999 10:22:23 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Doug Rabson 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, 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. > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message