Re: kernel upgrade on the fly

[Pavel Machek <pavel@suse.cz>]

Hi!

> > >>  has anybody worked or thought about a property to upgrade the kernel
> > >> while the system is running?  ie. with all processes waiting in their
> > >> queues while the resident-older kernel gets replaced by a newer one.
> > >
> > >Thought about, yes.  At length.  That's why it hasn't been done. :)
> >
> > IMO the biggest reason it hasn't been done is the existence of
> > loadable modules. Most driver-type development work can be tested
> > without rebooting.
> 
> That's part of it, sure.  (And I'm sure the software suspend work is 
> leveraging the ability to unload modules.)
> 
> There's a dependency tree: processes need resources like mounted filesystems 
> and open file handles to the network stack and such, and you can't unmount 
> filesystems and unload devices while they're in use.  Taking a running system 
> apart and keeping track of the pieces needed to put it back together again is 
> a bit of a challenge.

It depends on what limitations you can live with.

> The software suspend work can't freeze processees individually to seperate 
> files (that I know of), but I've heard blue-sky talk about potentially adding 
> it.  (Dunno what the actual plans are, pavel machek probably would).
> If 

Its not software suspend's goal; something similar can be done from
userspace using ptrace, try googling for freezer. Martin Mares did that.

> processes could be frozen in a somewhat kernel independent way (so that their 
> run-time state was parsed in again in a known format and flung into any 
> functioning kernel), then upgrading to a new kernel would just be a question 
> of suspending all the processes you care about preserving, doing a two kernel 
> monte, and restoring the processes.  Migrating a process from one machine to 
> another in a network clsuter would be possible too.

Yeah, that would be very nice.

> Hmmm, what would be involved in serializing a process to disk?  Obviously you 
> start by sending it a suspend signal.  There's the process stuff, of
> course.  

You don't. You don't want process being frozen known it was
freezed. You just stop it in a special way.

> (Priority, etc.)  That's not too bad.  You'd need to record all the memory 
> mappings (not just the contents of the physical and swapped out
> memory 

Doable from userspace, its in /proc.

> You'd need to record all the open file handles, of course. (For actual files 
> this includes position in file, corresponding locks, etc.  For the zillions 
> of things that just LOOK like files, pipes and sockets and character and 
> block devices, expect special case code).

There's not enough info in /proc to do this, I believe. Plus this is
nasty to restore -- like forcing code into processes's address space
to do opening for you.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa