On Sun, 24 Mar 2002, David O'Brien wrote:

> On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote:
> > Hmm.  The argument for A is, I think, is a lot stronger than for J, since
> > it comes without the performance impact, and you can actually generate
> > useful diagnostics.  I would be fine with leaving A in the developer
> > snapshot.
> Lets back up and clarify RE's goals for the DP#1.  Turning off all of
> our debugging options and appearing to make this benchmark ready were
> not part of what I [thought I] heard at the Kernel Summit at BSDcon.

The goal of DP's is to increase exposure of the development branch in some
key audiences, including the developer community, and community of early
adopters.  Part of the discussion that lead up to deciding to follow
through on the DP plan was the perception that many FreeBSD non-kernel
developers are not running 5.0, and that 5.0 had a "fear" element that
didn't seem to match with reality.  A part of addressing this is to
provide a window into which 4.x developers can try out 5.x with a lower
level of risk: this is why we had something that resembled a code slush,
and why when greenvm was committed during the code slush, we actually
backed it out of the DP branch (it was later also backed out of the main
development branch).  We want to provide a stable and usable version of
5.0, in as much as that is possible, to provide access to the new
features, services, APIs, etc.  We want a reproduceable install that ports
developers can use to learn more about the changing 5.0 environment, among
other things.

We will actually be offering at least three seperate kernels on the DP cd:

- GENERIC, which resembles a normal release GENERIC
- DEBUG, which has uber-debugging features
- NEWCARD, which offers the NEWCARD feature set

For future DPs, we'll lose the oldcard/newcard distinction so we'll cut
that out of the offering as soon as that is possible.  GENERIC will offer
the user something that they can use easily and effectively from the
install.  DEBUG turns on many debugging features, and will provide an easy
path to debug system problems without evening having to custom compile a
kernel.  Users will have the option of selecting "maximal debugging" to
attempt to track down problems and test the system.  They'll have the
option to select "Looks most like a release" to use for application
testing and porting, not to mention daily usage.

Something that phk and I have discussed out-of-band is the idea of keying
phkmalloc behavior to kernel selection.  I.e., exposing a policy sysctl
from the kernel, keyed to the kernel identity/option, causing phkmalloc to
behave different based on the kernel selection.  This would allow DEBUG to
turn on maximal debugging, but GENERIC to have phkmalloc behave "like a

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to