RE: [Lhms-devel] RE: memory hotremove prototype, take 3

[Luck, Tony]

> > Bingo...just the perfect excuse I need to give to my manager to keep
> > a low profile while tinkering around for a long time :)
> > 
> > Okay, so I will play a wee bit more the devil's advocate as an 
> > exercise of futility, if you don't mind. Just trying to compile a 
> > (possibly incomplete) quick list of what would be needed, can you 
> > guys help me? you know way more than I do:
> > 
> > 1) the core kernel needs to be independent of physical 
> memory position
> > 1.1) same with drivers/subsystems
> > 1.2) filesystems
> > [it cannot be really incomplete because I have added all the code
> > :/]
> 
> ...and you have bad problem at any place where physical address is
> passed to the hardware. UHCI is going to be "interesting".

Which is why this hot remove project is side-stepping all
those hard problems, and just dealling with the "easy" cases
of only allocating user memory to removeable physical memory.
This is useful for large systems made up of removeable nodes
(either to physically remove a node, or to logically re-assign
a node to a different "partition" in the machine).

Anyone who wants more than this is welcome to virtualize the
base kernel, filesystems, driver code etc. to allow hot remove
of the remainder of memory not dealt with by this patch :-)

-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/