![]() | ||||||||||
Messages in this thread |
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 | ||||||||||