From owner-freebsd-smp Mon Oct 23 9:32:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A5A1337B479 for ; Mon, 23 Oct 2000 09:32:45 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA04619; Mon, 23 Oct 2000 09:29:33 -0700 Date: Mon, 23 Oct 2000 09:26:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: src/sys/sys mutex.h In-Reply-To: <13301.972324795@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ taken to smp... ] > This was the warnings I talked about, hoping they would remind > the SMPng team about their brokenness... > > On i386 those were exactly warnings, they did not break the build. Broke it on alpha :-). It might actually break on an SMP kernel build for i386 too. Yeah- the deal here is that for each file that includes this, it whines. Ugly, but your point gets across. What I've done so far is to push this out to the file- and to move CURTHD out there too because that's where it'll need to be anyway. I'm test compiling the changes now so I can put back a new mutex.h that gives you what you want but doesn't pork the alpha kernel compiles. The ultimate problem is partially that proc.h is included in the wrong place throughout most of the kernel- it's included *after* buf/bio, but any SMP aware Unix system is likely going to need something either from proc.h, or some glue layer (call to assembler, most likely) that will yield the current thread ID, and places like buffer structures, etc., always have locks defined. Is there some reason that proc.h is included later? I mean, the right way to fix this whine breakage seems to me to go thru and put proc.h in the right place so that curproc and their ilk can be defined before being used. Formally speaking, I'd prefer to *not* have CURTHD just a static propagated define in mutex.h- but I suspect that a good performance argument could be made that for non-SMP machines that curproc is what this would resolve to anyway, and why pay even a trivial call/return cost to get it. Thoughts? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message