From: ebiederm@xmission.com (Eric W. Biederman)
To: Valdis.Kletnieks@vt.edu
Cc: thunder7@xs4all.nl, Gabe Foobar <foobar.gabe@freemail.hu>,
linux-kernel@vger.kernel.org
Subject: Re: will be able to load new kernel without restarting?
Date: 04 May 2003 01:39:51 -0600 [thread overview]
Message-ID: <m11xzfcg8o.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200305032252.h43Mq7X9006633@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu writes:
> On Sat, 03 May 2003 22:56:56 +0200, Jurriaan said:
>
> > > Just a simple question. When I will be able to load new
> > > kernel without restarting the system? Working anybody on
> > > this problem?
>
> > Check the archives for 'kexec'. Some success messages were posted even
> > today.
> >
>
> As I understand it, that's still restarting, just skipping the usual detour
> through the BIOS and lilo/grub/whatever.
>
> What he wants is the sort of on-the-fly upgrading that bellheads have grown to
> know and love, and which is NOT likely to be implemented for the entire Linux
> kernel anytime soon. Large sections can do it now with the "module" stuff, so
> you can rmmod the old one and insmod the new one.. but I don't see any easy way
> to implement rmmmod/insmod semantics for things like kernel/schedule.c (how
> would you get your next timeslice?). There's also issues with changing the
> API for something - it's hard to drop a 2.5.71 kernel/signals.c into a 2.5.70
> kernel if the API is different. Googling around will probably cough up
> lots of references to how the telcos do software upgrades - it basically
> involves LOTS of up-front design work to make sure all the details are
> addressed in the basic design of the system.
>
> Bottom line - you can do it now for things that can be built as modules,
> *if* it's something you can effectively rmmod and insmod. If it's not a module,
>
> or if it's the driver for something you can't rmmod (a disk or network driver,
> etc), you can't do it on-the-fly.
If you can checkpoint user space you can use kexec to load the new kernel.
So at this point we are approaching half way there. I don't know
where all of the work is for checkpointing but I do know there is a lot of interest
in it, and several partial implementations.
When replacing the entire kernel at least you have a stable ABI which
makes a number of things at least theoretically easier.
Eric
next prev parent reply other threads:[~2003-05-04 7:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-03 19:24 will be able to load new kernel without restarting? Gabe Foobar
2003-05-03 20:56 ` Jurriaan
2003-05-03 22:52 ` Valdis.Kletnieks
2003-05-04 7:39 ` Eric W. Biederman [this message]
2003-05-04 16:00 ` rmoser
2003-05-04 17:09 ` Jan-Benedict Glaw
2003-05-05 2:49 ` rmoser
2003-05-05 18:49 ` Timothy Miller
2003-05-05 18:56 ` Valdis.Kletnieks
2003-05-05 1:07 ` Felipe Alfaro Solana
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=m11xzfcg8o.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=foobar.gabe@freemail.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=thunder7@xs4all.nl \
/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