Date: Mon, 23 Oct 2000 11:59:09 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-smp@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mutex.h Message-ID: <Pine.LNX.4.21.0010231154250.9395-100000@zeppo.feral.com> In-Reply-To: <XFMail.001023114436.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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 > > <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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0010231154250.9395-100000>