From owner-freebsd-smp Mon Oct 23 11:47: 5 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id D765837B4C5 for ; Mon, 23 Oct 2000 11:47:02 -0700 (PDT) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9NIi0f27436; Mon, 23 Oct 2000 11:44:00 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <13423.972326495@critter> Date: Mon, 23 Oct 2000 11:44:36 -0700 (PDT) From: John Baldwin To: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/sys mutex.h Cc: freebsd-smp@FreeBSD.org, mjacob@feral.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23-Oct-00 Poul-Henning Kamp wrote: > In message , Matthew > J > acob writes: >>[ 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. > > 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... >>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. 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. >>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. > 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. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message