On Sat, 23 Mar 2002, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> : The RE's are wanting to ship 5.0 DP#1 w/this patch applied.
> : If having 'AJ' by default is deemed not useful (by being removed from the
> : DP), it sounds like we should just turn it off.
> : Unless there is strong objection, I plan on committing this.
> I think we should keep AJ enabled until at least DP2. It has found bugs
> in the past, and I suspect that a lot of new code is going in between
> now and then.
Not clear from your suggestion if you mean the branch or the dp's. My
feeling is that a useful strategy is:
- -CURRENT has AJ from inception of branch until final DP before release.
- DP's don't have AJ
AJ generates false positives in the form of third party application
behavior changes. When we're replacing things like the threading model,
etc, etc, I don't want application failures to be attributed to those
feature changes when they originate from memory junking. DP's offer an
opportunity for third party developers to explore the new feature set,
make sure their applications work with the new primitives, etc. While
forcing them to fix memory related bugs is a useful activity, doing it
with the DP seems to be a less useful activity.
- New protection settings for signalling break (fooapp)
- There appear to be thread problems related to file descriptors and KSE
- Changes in mmap behavior result in some applications with custom memory
- Some major application coredumps before it even pops up a window due to
referencing memory after a free but before it's reallocated, resulting
in ten or fifteen such bug reports
- Some X11 application usually run without a terminal on stderr dies
frequently due to violating a safety constraint; failure mode is
reported to us and prevents people from running that application,
meaning we don't learn about system bugs
- Some applications become incredibly slow and have very high loads, so
the DP can't be used out of the box for some server environments where
we'd like it to be used to maximize load on the system.
With new userland code coming into -CURRENT at a rapid rate, it may be
useful in -CURRENT for developers. For DPs, probably not.
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