linux-kernel - Re: x86 status was Re: -mm merge plans for 2.6.23

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 12 Jul 2007 01:29:25 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: x86 status was Re: -mm merge plans for 2.6.23

Linus,

On Wed, 2007-07-11 at 16:07 -0700, Linus Torvalds wrote:
> Why not just fix up the HPET code so that it can be shared *first*. 
> Without the other conversion? Really - What's so wrong with the hpet.c 
> changes in the *absense* of conversion to clockevents? Those changes seem 
> to be totally independent - just abstracting ou tthe 
> "hpet_get_virt_address()" stuff etc.
> 
> None of that has anything to do with clockevents, as far as I can see.
>
> In other words, you now change a i386-only file, and maybe it breaks 
> subtly on i386 as a result. Wouldn't it be nicer to see that breakage as a 
> separate event?

Sure, I meant to do the HPET changes to i386 separate as a preparatory
patch.

Sharing HPET before the conversion is nasty at best (it involves a ton
of ifdeffery at least).

> Then, the x86-64 clockevents code will switch over entirely, but now it 
> switches over to something we can say has gotten testing, and we know the 
> switch-over won't break any 32-bit code, because the switch-over literally 
> didn't change anything at all for that case.

Well, we know that it works on i386, but once we turn on the x64 switch
we have not tested the shared code for x64 yet.

I try to find some practicable compromise between the big bang patch and
the theoretical gradual optimum.

> The same is true of a lot of the APIC timer code. Sure, that patch has the 
> actual conversion in it, and you don't have the cross-architecture issues, 
> but more than 50% of the patch seems to be just cleanup that is 
> independent of the actual switch-over, no?

I said before, that I'm going to split them further.

	tglx


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