Date: Sun, 24 Mar 2002 13:59:56 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: current@FreeBSD.ORG Subject: Re: turning off malloc's AJ by default Message-ID: <Pine.NEB.3.96L.1020324134931.47668j-100000@fledge.watson.org> In-Reply-To: <20020324103200.B8262@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 release". Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020324134931.47668j-100000>