Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Oct 2000 09:26:42 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        freebsd-smp@freebsd.org
Subject:   Re: cvs commit: src/sys/sys mutex.h 
Message-ID:  <Pine.LNX.4.21.0010230917550.9395-100000@zeppo.feral.com>
In-Reply-To: <13301.972324795@critter>

next in thread | previous in thread | raw e-mail | index | archive | help
[ 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 <machine/globals.h> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0010230917550.9395-100000>