linux-kernel - Re: about relocs.c on x86

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: <1201774898.23523.23.camel@brick>
Date:	Thu, 31 Jan 2008 02:21:38 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: about relocs.c on x86

On Thu, 2008-01-31 at 11:11 +0100, Ingo Molnar wrote:
> * Harvey Harrison <harvey.harrison@...il.com> wrote:
> 
> > > during the big first phase of unification we generally kept file 
> > > names untouched if they were only present in one of the previous 
> > > architectures. I.e. pure 32-bit and pure 64-bit files were not 
> > > renamed to _32/_64.
> > > 
> > > Now that we've got lots of unified 32/64-bit files it might make 
> > > sense to rename the 'standalone' ones into _32/_64 if they share the 
> > > same directory with 32/64-bit source files - to reduce the 
> > > confusion. And given that for example 
> > > arch/x86/boot/compressed/misc.c is unified while 
> > > arch/x86/boot/compressed/relocs.c is 32-bit only, i'd agree with 
> > > your observation. Feel free to send a rename patch for such cases.
> > 
> > I'd argue that eliminating the _32/_64 suffixes through unification 
> > and not adding any more would be better.  Renaming at this point seems 
> > like the wrong side of the cost/benefit line.  When the makefiles 
> > finally get unified, that would be a natural list of what is 32 
> > bit-only and what is 64 bit-only, and additional suffixes wouldn't add 
> > much to that.
> 
> no strong opinion from me - but i think it should be obvious to the 
> developer when they are looking at a .c file that it's 32-bit only (or 
> 64-bit only). I.e. the default is that whatever .c file we look at is 
> unified - and in that sense relocs.c breaks that general expectation.
> 
> In fact renaming it to _32.c might spur its unification: people might 
> say "hm, this would be handy on 64-bit as well". We might even do that 
> to directories - so that for example arch/x86/math-emu/ would become 
> arch/x86/match-emu_32/.

They could just as easily do that in the original file rather than
renaming it once and then renaming it again someday when it has 64
bit functionality.  It's the potential for this double-rename that
really turns me off the idea.

> 
> ( Hey, and maybe someone is crazy enough to try to port the math-emu 
>   code to 64-bit and boot Linux up on 64-bit with all user-space FPU ops 
>   emulated. It would be one of the most useless hacks of all times, and 
>   that certainly has a certain kind of sick appeal to it, doesnt it? ;-))
> 
> but it's really not a big issue, we can certainly leave it alone and 
> observe the situation as more stuff gets unified. I'd expect it all fall 
> into place naturally.

Again, I can't tell people how to spend their time, but there isn't much
benefit over checking the makefile to see if it is shared for this case
that I can see.

IMHO

Harvey

--
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/