From owner-freebsd-smp Mon Oct 23 12: 2: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6727F37B479; Mon, 23 Oct 2000 12:02:05 -0700 (PDT) Received: from feral.com (feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD4886E3035; Mon, 23 Oct 2000 12:02:04 -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 MAA05304; Mon, 23 Oct 2000 12:02:01 -0700 Date: Mon, 23 Oct 2000 11:59:09 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Poul-Henning Kamp , freebsd-smp@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mutex.h In-Reply-To: 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 > > > > It didn't, I tested that. I don't have an alpha I can test on here, > > so my automatic scripts didn't cover that. > > ?? I must have missed a thread in here somewhere... Yes, alpha got borked. > Hang on a tick. We are going to be adding in a PCU_GET() macro soon for > accessing per-CPU data. Once this is done and the kernel source is changed > to use these macros, only machine/globaldata.h will be needed. Umm... too late! Sorry if I broke things! > > >>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. > > > > Well, my take on this is that the main problem is that curproc is two > > entirely different things for SMP vs UP. That clearly makes all KLD's > > toast unless compiled for the right thing. That needs fixed. > > It isn't b0rked. In machine/globaldata.h (or globals.h maybe) we use > the same function calls for accessing data for KLD's that we do for > SMP. The only case when we optimize to access the variables directly > is within a UP kernel. That's the point that Poul and I agree on (I think)- this is broken WRT KLDs- they can't (shouldn't) know whether they're on a UP or SMP. > > > In general "#ifdef SMP" should be minimized and in particular no > > KLD's should need to know about it. > > > > I think a function to get the current thread/proc should not require > > to be included, most places just need to pass a reference, > > they don't need to even know how the entrails of a proccess is > > arranged, so obviously they should not need #included.\ > > I have to have the type. The function returns a type. Yeah- but the type you're playing with currently is a kernel thread pointer. It just happens to be punned to curproc, or PCPU_GET(curproc) right now. In point of fact for mutex.h, you don't need any of the contents of what this CURTHD (punned to curproc) points to- you just use it as an identifier. I would suggest that in the case of mutex.h, just a function that returns a uintptr_t sized unique id is needed. This way you don't have to pollute every source file to have to know about the contents of a thread or a proc structure- *and* as a function you don't have to worry about how things got compiled [ note that I'm now moving from a question as to whether or not we want to do this to an assertion that we do ]. But since I'm not leading the design of this, I'll back away and let you and Poul work it out if you feel this isn't the right direction. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message