Re: will be able to load new kernel without restarting?

[Eric W. Biederman]

[e-mail] 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