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: <20080131103842.GA550@uranus.ravnborg.org>
Date:	Thu, 31 Jan 2008 11:38:42 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Harvey Harrison <harvey.harrison@...il.com>,
	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

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

I for one would like to see when stuff is 32 bit only and when
shared across 32 and 64 bit. 
And this type of info is useful when I do greps so hiding the information
in a Makefiel is then no good.

It helps your understanding when you get the most correct picture of
where a certain symbol is used - a functionality I often need.
And this is by no menas limited to a narrow x86 view but across
the full kernel.

So I, and this is no news for Ingo, would like to see what is
solely for 32 bit to be marked as such.

And we are heading with full speed to the situation for x86 where
the number of foo_32.c, foo_64.c are minimal.
But that said we will likely see a small decrease in speed now.

As for the Makefiles - I looked at them last time and only
issue that kept me away for unifying them was that I did
not understand the linking order requirments and I did not see
enough benefit at that time to invest the time to unify them.
Each of the remaining Makefile should be unifyable in less
than 10 steps each. It is just work that are waitng to be done.

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