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]

Date:	Fri, 21 Aug 2009 21:38:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Tobias Doerffel <tobias.doerffel@...il.com>,
	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


* Arjan van de Ven <arjan@...ux.intel.com> wrote:

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

makes sense.

	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/