No, actually, it wouldn't. Take it from someone who has actually
looked at the code with an eye to doing this.
Replacing static structures by dynamic ones for an architecture which
doesn't yet exist is NOT a good idea.
Trying to force a dynamic infrastructure into the static bitmap arrays
that we have is the bad idea, IMHO. Why on earth would you want offline
CPUs in the scheduler domains? Just to make your coding easier? Sorry,
but that just doesn't cut it for me.
Sure, if they were stupid they'd do it this way.
If (when) an architecture has hotpluggable CPUs and NUMA
characteristics, they probably will have fixed CPU *slots*, and number
CPUs based on what slot they are in. Since the slots don't move, all
your fancy dynamic logic will be wasted.
When someone really has dynamic hotplug CPU capability with variable
attributes, *they* can code up the dynamic hierarchy. Because *they*
can actually test it!
The cpu numbers are now dynamically allocated tags. I don't see why
we should sacrifice that just to get cpu hotplug. Sure, it makes your
coding a little harder, but ....
Yup ... but you don't have to enumerate all possible positions that way.Crap. When all the fixed per-cpu arrays have been removed from the
See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
Same thing applies.
kernel, come back and talk about instantiation and location of
arbitrary CPUS.
You're way overdesigning: have you been sharing food with the AIX guys?
A cheap shot. Please, I'd expect better flaming from you.
Sorry if this makes your coding harder, but it seems clear to me that
it's the right way to go. I guess the final decision is up to Andrew,
but I really don't want to see this kind of stuff. You don't start kthreads for every possible cpu, do you?