linux-kernel - Re: x86 merge: Keep kernel/cpu for CPU specific code?

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:	Tue, 13 Nov 2007 14:53:20 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"Robert Richter" <robert.richter@....com>
Cc:	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: x86 merge: Keep kernel/cpu for CPU specific code?

"Robert Richter" <robert.richter@....com> writes:

> x86 CPU specific code is currently implemented in different ways for
> 64 and 32 bit. While there are almost no CPU specific files for 64
> bit, there is the arch/x86/kernel/cpu/ directory for 32 bit. Is there
> already an idea about whether to use kernel/cpu also for 64 bit?

Well it's already used as it has been pointed out. 

Regarding the core initialization code:

The 32bit set up here is kind of crappy. Initcalls that are commented
out, weird ordering, unrelated stuff mixed toegether etc. If you
consider "improving" 64bit here then I would suggest to do some major
clean up in the 32bit parts first.

I personally consider the single file cleaner to hack, but then 64bit
is already vastly simpler anyways because it has much less CPUs to support.

If anything it would probably make sense to separate out generic
stuff (like GDT initialization) from CPU specific initialization.
64bit already separates that better too, but it's also not fully complete.

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