From owner-freebsd-smp Tue May 6 10:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22933 for smp-outgoing; Tue, 6 May 1997 10:29:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA22926 for ; Tue, 6 May 1997 10:29:39 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA18734; Tue, 6 May 1997 10:23:29 -0700 From: Terry Lambert Message-Id: <199705061723.KAA18734@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: steve@visint.co.uk (Stephen Roome) Date: Tue, 6 May 1997 10:23:29 -0700 (MST) Cc: terry@lambert.org, smp@csn.net, bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Stephen Roome" at May 6, 97 11:19:22 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It would help posters like this, now that the merge is done, to have > > an "SMP" file in /etc/i386/conf" for an SMP version of "GENERIC". > > I'm not sure that that is the problem area. I only just started with SMP, > and the biggest problem was not figuring out the config (as frankly there > really isn't much to do to make it work from a user point of view). This is not necessarily to help you, specifically. It's to remove the curb for people wanting to beat on the SMP kernel and provide feedback information to the SMP coders without requiring a lot of hand-holding in trade for the (needed) feedback. One effect this should have is that an SMP kernel should be built for the snap's (whech gets it on the CDROM). This won't happen without an "SMP GENERIC config" of some kind. > What was a lot harder was figuring what the options do. The new LINT may have > all (or many anyway) possible options in it, but most of them are poorly > explained and 50% of them aren't documented other than 2 words. The SMP options also need to be runtime instead of compile time configurable, based on flags values which can be modified at boot configuration time. This would let a single SMP kernel work on all hardware, regardless of which options must be twiddled to get it to go. The alternative is multiple "SMP GENERIC" configurations -- not a likely event. My suggestion was aimed at main-streaming the code so that there would be more feedback, while at the same time offloading some of the issues requring hand-holding to the standard UP kernel channels. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.