status of ppc64 patches

[Joel Schopp]

> 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 
still buggy.

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 
unmerged bits.

And I apologize for not making this all clear in my initial message.