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

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

[Robert Richter]

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?

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com

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

[Adrian Bunk]

On Tue, Nov 13, 2007 at 12:44:43PM +0100, Robert Richter wrote:
> 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?

It is also used for 64bit for years.

> Thanks,
> 
> -Robert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Robert Richter]

On 13.11.07 13:02:08, Adrian Bunk wrote:
> On Tue, Nov 13, 2007 at 12:44:43PM +0100, Robert Richter wrote:
> > 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?
> 
> It is also used for 64bit for years.

Yes, but almost all files in arch/x86/kernel/cpu/ depend on
CONFIG_X86_32.

Here is an example for similiar implementations:

arch/x86/kernel/cpu/amd.c:static void __cpuinit init_amd(struct cpuinfo_x86 *c)
arch/x86/kernel/setup_64.c:static void __cpuinit init_amd(struct cpuinfo_x86 *c)

The question is, will there be a CPU specific file such as amd.c?

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com

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

[H. Peter Anvin]

Robert Richter wrote:
> On 13.11.07 13:02:08, Adrian Bunk wrote:
>> On Tue, Nov 13, 2007 at 12:44:43PM +0100, Robert Richter wrote:
>>> 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?
>> It is also used for 64bit for years.
> 
> Yes, but almost all files in arch/x86/kernel/cpu/ depend on
> CONFIG_X86_32.
> 
> Here is an example for similiar implementations:
> 
> arch/x86/kernel/cpu/amd.c:static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> arch/x86/kernel/setup_64.c:static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> 
> The question is, will there be a CPU specific file such as amd.c?
> 

That's my current intent, as I consider the 32-bit code cleaner even 
though Andi disagrees.  That doesn't mean it's good enough as-is, of 
course, but I would like to maintain things reasonably well separated out.

	-hpa

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

[Andi Kleen]

"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