From owner-freebsd-smp Mon Dec 2 13:25:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14915 for smp-outgoing; Mon, 2 Dec 1996 13:25:26 -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 NAA14908 for ; Mon, 2 Dec 1996 13:25:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA22855; Mon, 2 Dec 1996 14:23:53 -0700 Message-Id: <199612022123.OAA22855@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: Terry Lambert cc: ccsanady@friley216.res.iastate.edu, freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/i386/include pmap.h In-reply-to: Your message of "Mon, 02 Dec 1996 13:47:06 MST." <199612022047.NAA11277@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Dec 1996 14:23:53 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Long term, I think I agree, I go back and forth on just what the model > > ... > [ ... expedient reasons ... ] > > ... > > The main line code should be changed, regardless. It would definitely > benefit from the changes, and the interrupt architectures for non-Intel > machines dictate a similar change be made for porting in any case. > > I would like to see the change driven by the SMP requirements, since > it would be much harder to go back and retrofit SMP if the changes > only considered the porting requirements, and not the SMP. > > The SMP code integration is going to be A Big Deal. If you can fit > some additional (good!) changes in under that umbrella, so much the > better. all valid points. I'm not arguing against this, only about when... look at it from this point of view. Peter currently merges SMP with -current every 4-8 weeks. At such a point in time we could call SMP-current '-current' and the transition would be complete. That is more or less how I see SMP getting into -current, with it being several steps as I outlined previously. If we start doing all the admittedly desirable changes as part of the merge process we will be burning much too much energy staying in sync with -current while we do it. I want: minor changes to SMP-current \ +-- start necessary long term changes. -current / Not: fix SMP-current, fix SMP-current, ... fix SMP-current \ +-- someday... fix -current, fix -current, ... fix -current / -- 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-----