> > >> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/