From owner-freebsd-hackers Tue May 6 15:25:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA09236 for hackers-outgoing; Tue, 6 May 1997 15:25:42 -0700 (PDT) Received: from pluto.plutotech.com (pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA09226; Tue, 6 May 1997 15:25:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id QAA10724; Tue, 6 May 1997 16:24:53 -0600 (MDT) Message-Id: <199705062224.QAA10724@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jason Thorpe cc: Steve Passe , "Jordan K. Hubbard" , "Jonathan M. Bresler" , hackers@FreeBSD.ORG Subject: Re: One last call for a show of hands on the ALPHA port... In-reply-to: Your message of "Tue, 06 May 1997 14:04:53 PDT." <199705062104.OAA21144@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 17:23:32 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > (2) change your "SMP" model... the current FreeBSD SMP code > seems to be the wrong approach to me. It feels like there > is a bunch of "this is a PC operating system" assumptions > in code that's in sys/kern (i.e. init_smp.c). Also, > the kernel isn't multi-threaded... I think you've done > this backwards, because the current model will mean more > work to multithread your kernel later. How can you completely test changes to make your kernel multi-threaded if you don't have support to start multiple processors? I would think any attempt to completely rewrite the kernel to be (theoretically) multi-threaded, running on multiple CPUs, without some way to test these changes incrementally is doomed to fail due to architectural oversights and the frustration of having everything break once you turn on the other processors. Although the current SMP code to bring up multiple processors may not be properly "modularized" so that architecture specific code is in an architecture specific file, this doesn't have anything to do with our "SMP model" since it hasn't been designed yet. I guess you could call "The GIANT lock" our "SMP model", but that is a stop gap allowing the bootstrapping code to be verified as well as experimentation with differnt synchronization techniques. Steve and others are now starting to look at designing the synchronization facilities that will allow us to become multi-threaded. So, once we have a real "SMP model", feel free to criticize us then. 8-) >Jason R. Thorpe thorpej@nas.nasa.gov >NASA Ames Research Center Home: 408.866.1912 >NAS: M/S 258-6 Work: 415.604.0935 >Moffett Field, CA 94035 Pager: 415.428.6939 > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================