status of ppc64 patches
jschopp at austin.ibm.com
Thu Oct 21 05:28:35 EST 2004
> As far as your patches are concerned, I am aware of two patches that
> change things so that we have __boot variants of __pa etc. However,
> your explanation didn't really get me excited about the change. You
> said something about "moving towards hotplug memory" but you didn't
> explain why these changes would help with that, or how I should choose
> which function to use when I'm making changes in future (that should
> actually go in a file somewhere under the Documentation directory), or
> why those changes need to go in now.
The direct answer is that this is a big part of the size of the
CONFIG_NONLINEAR patch, without the controversial part that actually
does CONFIG_NONLINEAR. CONFIG_NONLINEAR allows us to have big holes in
physical memory and to grow physical memory after boot. These changes
will be necessary for whatever ends up filling the role CONFIG_NONLINEAR
currently does in our hotplug memory tree. So even if you hate
CONFIG_NONLINEAR these patches will be necessary for memory hotplug
because we will have to differentiate early boot memory from normal memory.
We have a tree that does memory add, and is part of the way to doing
remove. http://sprucegoose.sr71.net/patches It has 76 patches
currently. It is a real job to continue to forward port it. We are
trying to get it all upstream. But of course it would be insane to
merge 76 very complex patches at once, especially when a few of them are
These changes need to go in now because they don't hurt anything and
they help us a great deal on a project most everybody agrees is a good
idea (memory hotplug). If we didn't have a continuous development model
they could be ignored until 2.7, but to get large features into a kernel
that is always stable it is necessary to merge things a bit at a time.
Even if those bits are only worthwhile in the context of the yet
And I apologize for not making this all clear in my initial message.
More information about the Linuxppc64-dev