Date: Mon, 18 Mar 1996 23:48:01 +0200 (EET) From: Narvi <narvi@haldjas.folklore.ee> To: Nate Williams <nate@sri.MT.net> Cc: hackers@FreeBSD.ORG Subject: Re: CFV: adding phk_malloc to -stable Message-ID: <Pine.BSF.3.91.960318233232.5604B-100000@haldjas.folklore.ee> In-Reply-To: <199603181752.KAA00617@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Mar 1996, Nate Williams wrote: > > > 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. OK. For some the phkmalloc is stable enough, the others think it should certainly not be as standard in stable while both sides (at least seem to) agree that people would benefit from it. So why not put there a separate brach, which would contain everything else standard but just the malloc replaced together with a warning sign? Or just put it among the other files and make it a command line switch for the Makefile? That everybody could get what they want - either real stability with bad memory allocation or stability with "not so stable malloc" + good memory allocation. (What happens if I allocate 1,000,000 structs containing a long and a pointer?) And the mailboxes would be saved of several and sevaral mails discussing this all. > > > Nate > Sander Eat good food, preserve nature, be nice to all nice people :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960318233232.5604B-100000>