Hey, great minds think alike 8)
> My patch does not take advantage of the DECLARE_PER_CPU macros, etc.
A minor optimization which can be done later. The important bit is
not creating entries for cpus where !cpu_possible(cpu).
> But it also
> offers node-topology info and per-node meminfo. I'd like to see them
> work together. Most of the conflict is simply in where we put the
> driverfs CPU code. Your patch moves it (w/ additions) to kernel/cpu.c,
> whereas mine moves it (also w/ different additions) to
> drivers/base/cpu.c. I think that the drivers/base is a bit more
> appropriate for the driverfs specific code (struct device_driver
> cpu_driver, the array of cpu_devices...). Also, I made the registration
> routines arch-specific, because I figured that different architectures
> may want to add arch-specific info, and register devices at different
> times, in different orders, etc. I also didn't incorporate the
> cpu_notifier stuff, which I should have.
>
> What do you think of my patch (other than the obvious that it conflicts
> with yours)?
If I'm reading correctly, you move the cpus under "node" dirs when
it's a NUMA system. I can see the cute appeal, but it makes it harder
to answer "how many cpus do I have?": a program would need to do a
"find" which is kinda icky (also hard to write HOWTOs). So I'd prefer
symlinks to the node, and no hierarchy.
driver/base/cpu.c should probably be moved into kernel/cpu.c anyway.
I think exposing the struct cpu array is a good idea, so archs can add
properties if they want (ie. node information).
But Patrick is the architect, I'm just a grunt, so it's his call 8)
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/