From owner-cvs-all Thu Jan 11 11:53:48 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 0F6DB37B404; Thu, 11 Jan 2001 11:53:17 -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 f0BJqM112132; Thu, 11 Jan 2001 11:52:22 -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: Date: Thu, 11 Jan 2001 11:52:48 -0800 (PST) From: John Baldwin To: =?ISO-8859-1?Q?G=E9rard_Roudier?= 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 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Jan-01 Gérard Roudier wrote: > > On Wed, 10 Jan 2001, John Baldwin wrote: > > Using too much upper-case names or kind of JUMBO-naming in C code does not > make the code more readable for the long run. It seems to me that all that > useless GROSS naming has been the result of having exacerbated the focus > of the day. Uppercase should be reserved mostly for stuff that is supposed > to be completely evaluated by compilation phases as: This is a style(9) issue. If style(9) dictates that these macros be lower-case, then so be it, but I haven't seen a reason for them to be lower case. >> at the old code, all these macros already existed, they just weren't used. >> (Instead we #define'd things liek curproc to GLOBAL_LVALUE_NV(curproc) and >> other weirdness). Also, Jake has another version of these macros that is >> more >> optimized that doesn't have the extra indirection. > > Indeed these ones are uglier. :-) Optimization != pretty in many cases. :) > Just, per-cpu variables are normally well-known variables, often > referenced and that donnot suffer of ordering problems in most places they > are referenced. They donnot seems to require to be over-focused for the > long run, in my opinion, and should as a result be naturally named, use > usual C lowercase naming and accesses should look lvalue-like in most > places. When the kernel becomes pre-emptive (a pre-emptive kernel is already stable on UP) the locking rules for most per-cpu variables will change (with the exception of curproc, curpcb, and things tied to the current thread of execution). You will no longer be able to cache and use per-cpu variables unless you hold a spin lock to prevent yourself from being pre-empted, since otherwise there is nothing to prevent an interrupt coming in and pre-empting your CPU and you end up running on some other CPU later. We want people to know that they are messing with a per-cpu variable that needs special treatment. > Gérard. -- 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