This seems like a reasonable strategy. If we do this, we'll need to expand the discussion of performance tuning and usability in the release notes for the DP. We'll also need to formalize the notion of DP3: right now we have only DP1 and DP2 formally scheduled, and DP2 is expected to have some bumps due to KSE hopefully becoming real for userland for that, and with the MAC code.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Robe > rt Watson writes: > > > >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". > > I said this as possible with a sysctl, I still think it is moderately > disgusting though. You can do the same thing more visible by having > /etc/rc* fiddle /etc/malloc.conf based on uname(1). > > >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 > > I would expect the three planned DP's to have these properties: > > One DEBUG kernel with: > INVARIANTS > WITNESS > DDB > One GENERIC kernel with: > INVARIANTS > DDB > Userland: > DP1 + DP2: malloc AJ > DP3: malloc A > > Now, I also have to say that I'm not going to do any of this, so > this will be my last email on the topic: Do whatever you think is > the right thing to do. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
