lkml.org 
[lkml]   [2002]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kernel upgrade on the fly
    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
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.027 / U:0.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site