lkml.org 
[lkml]   [2003]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 13:59    [W:0.057 / U:1.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site