From owner-freebsd-advocacy Fri Mar 24 11:48: 6 2000 Delivered-To: freebsd-advocacy@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 855F637B780; Fri, 24 Mar 2000 11:47:52 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id MAA11205; Fri, 24 Mar 2000 12:46:50 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpdAAAFYaiTv; Fri Mar 24 12:46:44 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id MAA07990; Fri, 24 Mar 2000 12:47:33 -0700 (MST) From: Terry Lambert Message-Id: <200003241947.MAA07990@usr09.primenet.com> Subject: Re: New article To: kris@FreeBSD.org (Kris Kennaway) Date: Fri, 24 Mar 2000 19:47:32 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dcs@newsguy.com (Daniel C. Sobral), wes@softweyr.com (Wes Peters), mwlucas@blackhelicopters.org (Michael Lucas), advocacy@FreeBSD.org In-Reply-To: from "Kris Kennaway" at Mar 23, 2000 05:35:08 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The legacy stuff, yes. I said so. :-) The kernel options... As I said > > > *some* as unavoidable. INVARIANTS? > > > > Get rid of all invariants. > > options INVARIANTS turns on enforcement of invariants in the kernel as a > debugging aid. I'm not sure how it could be done dynamically at load time > without building two versions of all the modules. Perhaps it should be > made mandatory, but the slight performance penalty associated with it > might be a turnoff. That's done at compile time, as a command line option. A debug kernel is an exceptional condition. I thought you were referring to "invariants", as in "not permitted to vary after compilation". > SMP/non-SMP is another case which has its conditional fingers in the > code. When you multiply all of the options together, having 2^n different > option combinations for each base module suddenly doesn't look so > attractive.. Right. So get rid of the things, and enable SMP support on all kernels. Yeah, this particular case might be overkill, but it's probably not: UnixWare actually got 30% faster on UP after the SMP support went in, since allowing the kernel to be reentrant made SMP-style locking mandatory on UP kernels, but the increase in concurrency more than made up for the overhead. This was in 1993/1994, BTW. There's no rational reason for hard coding things like the number of PCI busses, or anything else that can reduce functionality by virtue of being hard-coded (or even cause a panic, as in the mbuf case, even when there are resources available which could have been used to satify the request, instead of panic'ing). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message