Date: Mon, 18 Mar 1996 10:52:11 -0700 From: Nate Williams <nate@sri.MT.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: nate@sri.MT.net (Nate Williams), hackers@FreeBSD.ORG Subject: Re: CFV: adding phk_malloc to -stable Message-ID: <199603181752.KAA00617@rocky.sri.MT.net> In-Reply-To: <199603181739.SAA00856@labinfo.iet.unipi.it> References: <199603181602.JAA04404@rocky.sri.MT.net> <199603181739.SAA00856@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603181752.KAA00617>