Date: Wed, 20 Feb 2002 17:10:48 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Alfred Perlstein <bright@mu.org> Subject: Re: John Balwdin's proc-locking patch Message-ID: <200202210110.g1L1Amw91277@apollo.backplane.com> References: <XFMail.020220172730.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>> > :>> > That is my position. :>> :>> I've felt the same way for a while. :> :> Nobody is disputing that. It would have been better if John had committed :> it piecemeal, but it didn't work out that way. I doubt he'll fall for this :> trap again. : :Actually, I tried to do it piecemeal and ended up with a kernel that wouldn't :boot. :( : :-- : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Well... try again. If something ought to be compatible in a piecemeal commit and isn't, then something unexpected happened and you need to find out what it was. Doing a full-on commit for something like the proc lock patch is far too dangerous. It's just too large a patch set and we know from experience (cam, softupdates, etc...) that having a small handful of people testing a large private patch is not going to find all the bugs. This is why I introduced the mtx_lock_giant() family of calls in the first place .. to allow pushdown work to be committed piecemeal without turning Giant off, so developers working on unrelated subsystems don't get unexpected timing changes or crashes if, for example, you forget to PROC_LOCK a particular piece of code. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202210110.g1L1Amw91277>