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: <p73ejeuz1yn.fsf@bingen.suse.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ