Date: Sat, 19 Jun 1999 10:22:23 -0400 (EDT) From: "Brian F. Feldman" <green@unixhelp.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>, Ruslan Ermilov <ru@ucb.crimea.ua>, ugen@xonix.com, hackers@FreeBSD.org, luigi@FreeBSD.org Subject: Re: Introduction Message-ID: <Pine.BSF.4.10.9906190938220.99153-100000@janus.syracuse.net> In-Reply-To: <Pine.BSF.4.05.9906191357100.80685-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Jun 1999, Doug Rabson wrote:
> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
>
> > Ruslan Ermilov <ru@ucb.crimea.ua> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906190938220.99153-100000>