From owner-freebsd-smp Mon Dec 2 14:03:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17016 for smp-outgoing; Mon, 2 Dec 1996 14:03:48 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA17010 for ; Mon, 2 Dec 1996 14:03:44 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vUgS4-0003xRC; Mon, 2 Dec 96 14:03 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id XAA03015; Mon, 2 Dec 1996 23:04:21 +0100 (MET) To: Steve Passe cc: Chris Csanady , 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:44:18 MST." <199612022044.NAA22589@clem.systemsix.com> Date: Mon, 02 Dec 1996 23:04:20 +0100 Message-ID: <3013.849564260@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199612022044.NAA22589@clem.systemsix.com>, Steve Passe writes: >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 chang >es >> >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, an >d >> 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: Steve, this is not really a choice. SMP will not really be an option, since a lot of interfaces to the kernel (curproc being but one) will change. People will have LKM's accesing the wrong kind of lkm and it will be a proper mess. We are going to make the change once, and we're not going to have two different versions of those interfaces around (IMO) I would also say that I think it would be a good idea if you started to look at merging the smp stuff into the lite2 tree, since the first merge that will happen is probably the lite2 tree into current. That said, I think that it is correct that we need to think and decide on a structure and layout of SMP versus UP kernel. In particular somebody should think VERY hard about what bits are MI and what are MD bits in the SMP stuff. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail.