On Fri, Apr 27, 2007 at 05:18:16PM -0700, Jeremy Fitzhardinge wrote:While that would certainly be nifty, I think we're arguably starting from the wrong point here. Why are we booting a kernel, trying to poke the hardware back into some sort of mock-quiescent state, freeing memory and then (finally) overwriting the entire contents of RAM rather than just doing all of this from the bootloader? Given the time spent in kernel setup and unpacking initramfs nowadays, I'm willing to bet it'd still be faster even if you're stuck using int 13 on x86. http://apcmag.com/5873/page14 suggests that Intel is looking into this, but I haven't heard anything more yet. To the best of my knowledge, this is also how Windows manages things. -- Matthew Garrett | mjg59@srcf.ucam.org -
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | -mm merge plans for 2.6.23 |
| KAMEZAWA Hiroyuki | Re: 2.6.23-mm1 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
git: | |
| Alan Cox | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
