From: Andi Kleen <andi@firstfloor.org>
To: "Robert Richter" <robert.richter@amd.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"LKML" <linux-kernel@vger.kernel.org>
Subject: Re: x86 merge: Keep kernel/cpu for CPU specific code?
Date: Tue, 13 Nov 2007 14:53:20 +0100 [thread overview]
Message-ID: <p73ejeuz1yn.fsf@bingen.suse.de> (raw)
In-Reply-To: <20071113114443.GG18993@erda.amd.com> (Robert Richter's message of "Tue\, 13 Nov 2007 12\:44\:43 +0100")
"Robert Richter" <robert.richter@amd.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
prev parent reply other threads:[~2007-11-13 13:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 11:44 x86 merge: Keep kernel/cpu for CPU specific code? Robert Richter
2007-11-13 12:02 ` Adrian Bunk
2007-11-13 14:14 ` Robert Richter
2007-11-13 17:59 ` H. Peter Anvin
2007-11-13 13:53 ` Andi Kleen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p73ejeuz1yn.fsf@bingen.suse.de \
--to=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=robert.richter@amd.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox