From owner-freebsd-hackers Sat Jun 19 6: 3:15 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 84CCD14E7A; Sat, 19 Jun 1999 06:03:09 -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 OAA80968; Sat, 19 Jun 1999 14:03:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 19 Jun 1999 14:03:34 +0100 (BST) From: Doug Rabson To: Dag-Erling Smorgrav Cc: Ruslan Ermilov , ugen@xonix.com, green@unixhelp.org, committers@freebsd.org, hackers@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 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. -- 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