From owner-freebsd-smp Wed May 7 06:26:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA21936 for smp-outgoing; Wed, 7 May 1997 06:26:37 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21930 for ; Wed, 7 May 1997 06:26:34 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id OAA07053; Wed, 7 May 1997 14:37:01 +0100 (BST) Date: Wed, 7 May 1997 14:37:01 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: freebsd-smp@freebsd.org Subject: Re: Where to start SMP? In-Reply-To: <199705061723.KAA18734@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 6 May 1997, Terry Lambert wrote: > > > 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. Yup, sorry, following on from the conversation though, in the interests of helping people just documenting the options better would be a nice idea. What you say though is a different matter. > > 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. A nice option would be a choice of kernel from the install menu. SMP or UP. (perhaps it can decide for you ?) > > > > 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. Maybe, but surely some of the changes to run an efficient SMP system should come at kernel compile level. Unless FreeBSD moves to a modular system on the scale of something like HURD this looks likely to decrease performance. > > > 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. > Hand holding gets a user base, don't knock it. It worked for Windows. > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522