Date: Mon, 23 Oct 2000 11:44:36 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-smp@FreeBSD.org, mjacob@feral.com Subject: Re: cvs commit: src/sys/sys mutex.h Message-ID: <XFMail.001023114436.jhb@FreeBSD.org> In-Reply-To: <13423.972326495@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Oct-00 Poul-Henning Kamp wrote: > In message <Pine.LNX.4.21.0010230917550.9395-100000@zeppo.feral.com>, 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 <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. 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 > <sys/proc.h> 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 <sys/proc.h> #included.\ I have to have the type. The function returns a type. -- John Baldwin <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001023114436.jhb>