From owner-freebsd-hackers  Sat Feb  1 17:00:35 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA21287
          for hackers-outgoing; Sat, 1 Feb 1997 17:00:35 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA21277
          for <hackers@freebsd.org>; Sat, 1 Feb 1997 17:00:32 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA07122; Sat, 1 Feb 1997 17:58:35 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199702020058.RAA07122@phaeton.artisoft.com>
Subject: Re: Device driver help needed...
To: joerg_wunsch@uriah.heep.sax.de
Date: Sat, 1 Feb 1997 17:58:35 -0700 (MST)
Cc: mcgovern@spoon.beta.com, hackers@freebsd.org
In-Reply-To: <Mutt.19970202014250.j@uriah.heep.sax.de> from "J Wunsch" at Feb 2, 97 01:42:50 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> curproc is an ugly thing in an SMP environment, since there are
> multiple current processes.

Generic implementation strategy is to replace CURPROC with a macro.

I believe the current SMP code references the curproc out of the
processor specific data area, along with the kernel stack.  It's
really questionable whether this is a good idea, if we ever intend
to support kernel multithreading.  But as things stand now, you
still use "curproc", and you get the right one for the CPU you
are running on.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.