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.
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.
> > 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
- 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.