linux-kernel - Re: Atom processor inclusion

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: <4A8EE606.7000807@linux.intel.com>
Date:	Fri, 21 Aug 2009 11:23:02 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Tobias Doerffel <tobias.doerffel@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Kelly Bowa <kelly.bowa@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Atom processor inclusion

H. Peter Anvin wrote:
> On 08/20/2009 05:33 AM, Tobias Doerffel wrote:
>> Hi,
>>
>> Am Donnerstag, 20. August 2009 12:50:29 schrieb Ingo Molnar:
>>> Yep, it looked acceptable - Tobias, do you have any
>>> updates / latest version of that patch?
>> No - it's still the improved version I posted at the end of May [1]. The 
>> question is what to do with MODULE_PROC_FAMILY (CORE2 or ATOM) and the mtune-
>> fallback (generic, i686, ...)?
>>
> 
> Without benchmarks, we're flying blind on that one... although in
> general, "generic" is probably best in the sense that it doesn't imply
> that anything else has been done to it.
> 
> As far as MODULE_PROC_FAMILY it really comes down to if we use movbe or
> not, which I don't believe your patch does.  On the other hand, I really
> think it's extremely unlikely that anyone will use modules compiled for
> a different CPU, so I'm personally fine with changing that string.
> 
> That whole mechanism is kind of broken, anyway.
> 

personally, I would prefer it if we did a simple hash of the WHOLE cflags,
and put that into the module version string.
Anything else is just a weak, and useless, substitute for that.

Using different CFLAGS in any shape or form should disqualify the module
as "incompatible".. and a simple hash is sufficient for that.....
--
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/