From owner-freebsd-smp Mon Dec 2 12:44:29 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA12209 for smp-outgoing; Mon, 2 Dec 1996 12:44:29 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA12201 for ; Mon, 2 Dec 1996 12:44:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA22589; Mon, 2 Dec 1996 13:44:18 -0700 Message-Id: <199612022044.NAA22589@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Chris Csanady cc: freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/i386/include pmap.h In-reply-to: Your message of "Mon, 02 Dec 1996 14:27:38 CST." <199612022027.OAA04003@friley216.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Dec 1996 13:44:18 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >The next step would be to break up files that have grown to have alot > >of SMP stuff mixed with standard stuff, eg. init_main.c -> init_main.c & > >init_smp.c. Stated another way, I think we should strive to keep SMP changes > >localized to SMP specific files to the extent that it is practical. > > For now perhaps. But wouldn't the end goal be to have the UP instance just > 1 processor SMP case? Im thinking that this would make the code cleaner, and > more generic in the end. I think having kernel threads would be well worth > it. Long term, I think I agree, I go back and forth on just what the model should look like. For the short term I have many reasons for my "minimal impact" model: making an SMP kernel that boots & runs on a uniprocessor board is currently impossible for a lot of 'architectural' reasons, ie alot would have to change in the mainline code to make this work. Look at how we pervert things like curproc for an example. such a model allows us to arrive at a starting point from which everyone can view what is done to support SMP, without changing the code base in which they feel comfortable. we don't upset -current devvelopers who are unconcerned about SMP by changing the areas they are working on. we don't bog down in 'political' battles about what should change and why. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----