Date: Thu, 11 Jan 2001 11:52:48 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Bruce Evans <bde@zeta.org.au>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org> Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c machdep.c mp_mac Message-ID: <XFMail.010111115248.jhb@FreeBSD.org> In-Reply-To: <Pine.LNX.4.10.10101111908440.1606-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010111115248.jhb>