[Top] [All Lists]

Re: patch like kexec for MIPS possible?

To: Robert Michel <>
Subject: Re: patch like kexec for MIPS possible?
From: Thiemo Seufer <>
Date: Sun, 6 Feb 2005 01:28:09 +0100
Cc: linux-mips <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mutt/1.5.6+20040907i
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.
> 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?


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

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


<Prev in Thread] Current Thread [Next in Thread>