From owner-freebsd-hackers Mon Mar 18 09:50:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09119 for hackers-outgoing; Mon, 18 Mar 1996 09:50:40 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA09112 for ; Mon, 18 Mar 1996 09:50:37 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA00617; Mon, 18 Mar 1996 10:52:11 -0700 Date: Mon, 18 Mar 1996 10:52:11 -0700 From: Nate Williams Message-Id: <199603181752.KAA00617@rocky.sri.MT.net> To: Luigi Rizzo Cc: nate@sri.MT.net (Nate Williams), hackers@FreeBSD.ORG Subject: Re: CFV: adding phk_malloc to -stable In-Reply-To: <199603181739.SAA00856@labinfo.iet.unipi.it> References: <199603181602.JAA04404@rocky.sri.MT.net> <199603181739.SAA00856@labinfo.iet.unipi.it> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Actually, we aren't supposed to to be adding extensions to the system or > > kernel in -stable. However, some things slip through because they are > > I would just like to remember that the introduction of slices left > a bunch of disk-related stuff broken for a long time (I'd say > between 2.0.5 and 2.1), and gave the final shot to msdosfs, which > in turn caused some coexistence problems with msdos systems. And the slice support was only brought into -stable after much gnashing of teeth and incredible PR by the release engineer. After all, he's the guy who is responsible for making the release. > I agree that -stable must be stable, I am only criticizing the fact > that the above requirement for making changes to -stable are too > strict and impossible to fulfill (and I hope the maintainers of > -stable use weaker requirements). Nope. There are *lots* of fixes and such made to stable that follow all the rules set out. I bring in almost *all* of my changes into -stable since they are completely disabled extensions (PC-CARD) and/or bug-fixes for the current code (man page changes, simple bug-fixes, etc..) > > Broken-ness aside, there is also the appearance of brokeness. Some of > > the strengths of phkmalloc for a developer are weaknesses to a user. > > There are still bugs fixed in -current which haven't been brought back > > into -stable that are revealed by phkmalloc. I've found at least one > > new one, but I haven't been able to track it down (yet). > > Can you please mention where this one occurs ? I can't repeat it now, but it happened when I had a shell script with a non-existant shell earlier yesterday. I'm not sure how to repeat it, but in any case it *was* repeatable then, and it wasn't obvious which program was generating the error. (I suspect /bin/sh). > > The appearance of bugs makes people think something is wrong when in > > fact it might not be. Some of the recent kernel messages are a good > > example of 'un-necessary' information. Whenever someone sees this > > message, the user immediately assumes something is wrong when in fact > > it's an information only message. In the same manner, the messages > > phkmalloc spits out would only confuse normal users. > > This happens all the time with all parts of the system. fdisk had > similar problems (or still has, I don't know) about an unnecessary > ioctl for wd disks. And this 'bug' should be fixed. Just because it isn't in other parts of the system doesn't make it 'OK' to do with phkmalloc. > If the problem with phkmalloc is in some verbose behaviour, then > just rephrase the messages or make a less verbose mode the default > before inserting it into -stable. The issue is that it's obvious that all of the possibilities have not been found out with phkmalloc since there are still bugs popping up. Just recently Poul fixed a fence-post error in the allocator, so I'm still not convinced it's stable material. *However*, I *am* running it on one of my -stable systems so that I can find possible bugs, but I'm willing to take chances (and have good backups). When in doubt, I try to err on the conservative side which *may* penalize some users, but it may also make the system more usable (and secure, and robust, and consistant, etc...) by more users. Nate