linux-kernel - Re: [PATCH 13/21] amd64_edac: add f10-and-later methods-p3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090430104240.GA6769@elte.hu>
Date:	Thu, 30 Apr 2009 12:42:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Borislav Petkov <borislav.petkov@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, greg@...ah.com, tglx@...utronix.de,
	hpa@...or.com, dougthompson@...ssion.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/21] amd64_edac: add f10-and-later methods-p3


* Borislav Petkov <borislav.petkov@....com> wrote:

> Hi,
> 
> On Wed, Apr 29, 2009 at 10:47:30PM +0200, Ingo Molnar wrote:
> 
> [..]
> 
> > What i point out below is precisely what you say is ineligible 
> > under:
> > 
> > > > Of course, we don't have to use StinkyIdentifiers anywhere else.  
> > 
> > I'd extend that rule to say that StinkyIdentifiers should only be 
> > used for hw API definitions/constants - macros, enums - not really 
> > local variable names. The moment they are allowed into local 
> > variables the stuff below happens.
> 
> to agree with Andrew, at a certain point in time I thought that 
> having the same register bit names as in the docs would be 
> preferential when you look at the docs and what the code does. But 
> Ingo's also quite right: we can't have "normal kernel coding 
> style" and StinkyIdentifiers
> :) in the same source file.
> 
> /me locking himself back in the patch creation basement.

I think you can still cleanly use those identifiers for hardware 
constants, register offsets and similar. But if it shows up in a 
variable (or function) name, it has spread too far IMHO :-)

And it's not like we dont have our own historic mistakes in that 
area, right in the heart of Linux - just type:

  git grep Page mm/*.c

and cringe.

IIRC i might even have added a new method or two to that array of 
CrappyPageAPIs, many years ago. (back in the days when i wrote lot 
of crappy code myself ;-) Oh, PageHighMem() it is.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/