linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mark Hatle <fray@mvista.com>
To: Grant Erickson <erick205@umn.edu>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Solutions for Fast Software Upgrade in Linux/PPC
Date: Tue, 25 Sep 2001 10:42:34 -0500	[thread overview]
Message-ID: <3BB0A5EA.A8F7392D@mvista.com> (raw)
In-Reply-To: Pine.SOL.4.20.0109251001370.4999-100000@garnet.tc.umn.edu


Grant Erickson wrote:
>
> I am embarking on a project in which there exists a requirement to take my
> embedded system (Walnut board w/ PowerPC 405GP w/ raft of PCI devices) and
> allow it to perform a near-zero downtime upgrade/downgrade of
> software/firmware.
>
> Of the belief that there are very few new problems, just solutions that
> aren't widely known, I have to imagine that the telecommunications carrier
> equipment people have solved this problem long ago--albeit probably not
> with Linux.
>
> Does anyone know of any commercial or public solutions addressing this
> problem in Linux or Linux on the PowerPC?
>
> Anyway, there are a few solution spaces I can envision:
>
> 1. Check point all of your driver and application state, reboot, and
>    hope that you can warm-start with your check pointed state quickly.
>
>    - This means massaging the boot code, the Linux kernel, the device
>      drivers, and the applications to tweak their start-up time.
>
>    - At best, you may just quell kernel printks and disable auto-boot
>      countdown in the PROM, at most, buying you a few seconds, if that. If
>      it's a few seconds out of five, great. If it's a few out of twenty,
>      you've got a lot of work to do--maybe you'll get there...maybe not.

One note.. this has been discussed a lot on the linux kernel mailing
list (well a lot in the past at least.)  If all you will be doing is
maintaining the SAME kernel version till the end of time, and not
changing "critical" datastructures this "upgrade in place" can work.
However, even when moving minor versions of the kernel internal data
structures can change you you run into massive problems...  I would
suggest you scan the linux kernel mailing list (in addition to whatever
someone on this list suggests of course.)

--Mark

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-09-25 15:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-25 15:38 Solutions for Fast Software Upgrade in Linux/PPC Grant Erickson
2001-09-25 15:42 ` Mark Hatle [this message]
2001-09-25 15:48   ` Jim Thompson
2001-09-25 16:22 ` Peter Desnoyers
2001-09-26 15:51 ` Josh Huber
2001-09-26 22:53   ` Magnus Damm
2001-09-26 15:52 ` Josh Huber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BB0A5EA.A8F7392D@mvista.com \
    --to=fray@mvista.com \
    --cc=erick205@umn.edu \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).