Date: Sat, 19 Jun 1999 15:37:26 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Brian F. Feldman" <green@unixhelp.org> 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.05.9906191536050.80685-100000@herring.nlsystems.com> In-Reply-To: <Pine.BSF.4.10.9906190938220.99153-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906191536050.80685-100000>