lkml.org 
[lkml]   [2003]   [Dec]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 4 Dec 2003 12:01:01 +0100
FromPavel Machek <>
SubjectRe: [Lhms-devel] RE: memory hotremove prototype, take 3
Hi!

> > > I still think we could use the CPU's virtualization mechanism--of course,
> > > and as you and Tony Luck mention, we'd had to track down and modify the
> > > parts that assume physical memory et al. That they use large pages
> > > or
> > 
> > ...which means basically auditing whole kernel, and rewriting half of
> > drivers. Good luck with _that_.
> 
> 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".
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:59    [from the cache]
©2003-2008