Salve Thiemo! Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h: > MIPS kernels are usually position dependent code, and loaded in > unmapped memory, so a kernel would need to overwrite itself for > kexec. I don't know if kexec is flexible enough to handle this. Kexec is written for x86 (yet) - but the (my) question is if this would be possible with MIPS, too. --snip-- The magic of kexec One of the biggest challenges in the development of kexec comes from the fact that the Linux kernel runs from a fixed address in memory. This means that the new kernel needs to sit at the same place that the current kernel is running from. On x86 systems, the kernel sits at the physical address 0x100000 (virtual address 0xc0000000, known as PAGE_OFFSET). The task of overwriting the old kernel with the new one is done in three stages: 1. Copy the new kernel into memory. 2. Move this kernel image into dynamic kernel memory. 3. Copy this image into the real destination (overwriting the current kernel), and start the new kernel. --snap-- http://www-106.ibm.com/developerworks/library/l-kexec.html?ca=dnt-518 > > IMHO would such a kernel patch would be handy, especialy for > > small MIPS Linux boxes. For more info about kexec read e.g. > > http://www-106.ibm.com/developerworks/linux/library/l-kexec.html > > Frankly, I don't see what kexec is good for. Who else besides > kernel developers would need to reboot a machine continuously? Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS bootlaoders support USB-sticks or booting via VPNs? LinuxBios is a "nice" project, but for most boards/boxes Linuxer could be happy to be able to boot it - to develop a nice boadloader is depended from the hard/firmware of the systems. A kernel with a kexec like patch could be used into the bootchain for several reasons: - making developing and hacking more easy - booting with options - choice which kernel to boot - booting from original not supported devices (usb, network) - remote control for the boot process - bypassing memoryrestrictions of the bootloader - more flexibility - independance from proprietary bootloader - developing security, statistic features... - fail save boot - starting restore system, analyse tools.... - option for modular system - for upgrades lower downtimes (Router, Firewalls....) - perversive computing, the box could be on a place without physicaly access - the kernel would be more often updated, than the bootloader - just for fun - just because it could be usefull - an implemented feature may become the base for other features - unthinkable before this first step - ... So my point is not to boot a machine continuously, but to expand the bootchain: IMHO would be the most powerfull and flexible way to boot a linux kernel, to boot it just from an other linux kernel. ;) Greetings rob
