linux-mips
[Top] [All Lists]

Re: patch like kexec for MIPS possible?

To: Robert Michel <news@robertmichel.de>
Subject: Re: patch like kexec for MIPS possible?
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Date: Sun, 6 Feb 2005 01:28:09 +0100
Cc: linux-mips <linux-mips@linux-mips.org>
In-reply-to: <20050205191110.GD3071@mail.robertmichel.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050205165019.GC3071@mail.robertmichel.de> <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> <20050205191110.GD3071@mail.robertmichel.de>
Sender: linux-mips-bounce@linux-mips.org
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.
[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

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