Robert Michel wrote: > 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. [snip] > 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. Ok, so is no exception WRT. > > 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? No. > Does GRUB support SSH2? No idea. > Does most MIPS bootlaoders support USB-sticks or booting via VPNs? There are various, and usually they are open source, ao adding such features shouldn't be a problem. [snip] > - making developing and hacking more easy Usually done via netboot or JTAG download. > - 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 Those things should be fixed in the bootloader. > - developing security, statistic features... > - fail save boot > - starting restore system, analyse tools.... > - option for modular system ? > - for upgrades lower downtimes (Router, Firewalls....) 30 seconds for the tftp, and you have to hope the previous kernel left everything in a sane state. > - perversive computing, the box could be on a place without > physicaly access You don't want to do that without a safe fallback (aka serial console). > - 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. > ;) What if any of both is buggy? Either you have a working fallback, or you'll be screwed sooner or later. Thiemo
