From owner-cvs-all Thu Jan 11 10:40:27 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4AF5C37B404; Thu, 11 Jan 2001 10:40:07 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0BIdb110183; Thu, 11 Jan 2001 10:39:37 -0800 (PST) (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: <200101110428.f0B4Rcs23445@aslan.scsiguy.com> Date: Thu, 11 Jan 2001 10:40:02 -0800 (PST) From: John Baldwin To: "Justin T. Gibbs" Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c machdep.c mp_mac Cc: Bruce Evans , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder , =?ISO-8859-1?Q?G=E9rard_Roudier?= Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Jan-01 Justin T. Gibbs wrote: >>No, shared variables are just variables. Here is the problem. There is no >>'curproc' variable. There is a gd_curproc member of a struct globaldata, and >>each CPU has a struct globaldata tied to it. We can obtain it via >>PCPU_GET(curproc), or set it via PCPU_SET(curproc, myproc). Having a >>'curproc >>' >>"magic" variable that doesn't exist that we assume we can read and write to >>like any other variable is a lot more hokie than admitting that we are >>accessing a special variable in a special way. > > Anyone touching these variables had better understand what they are for > and how they operate. I think our developers are smart enough to understand > this without ugly upper-case macros. Heck "errno" is not spelled > PTHREAD_GET(errno), or PTHREAD_SET(errno, error) and still people seem > to be able to write useful threaded apps. 8-) Erm, I didn't know that all developers that ever touched the kernel needed to memorize all the various MD header files machine/globals.h and machine/globaldata.h for _each_ architecture. I guess we want the learning curve so high that no one else can submit code? :-P > The only thing that worries me about curproc and others like it is > that the macros can polute the kernel name space. Just try using "current" > as a local variable or structure field in linux x86 to see what I mean. > 8-) Changing to use PCPU_GET() (which is what BSD/OS uses, FWIW) will remove all the ugly macros for curproc and the like that we have now, so it will significantly cutdown on namespace pollution, assuming I'm reading you correctly. > -- > Justin -- 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 cvs-all" in the body of the message