From owner-freebsd-hackers  Wed Aug  6 11:21:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA11189
          for hackers-outgoing; Wed, 6 Aug 1997 11:21:13 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA11183
          for <hackers@FreeBSD.ORG>; Wed, 6 Aug 1997 11:21:06 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14438; Wed, 6 Aug 1997 11:17:13 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199708061817.LAA14438@phaeton.artisoft.com>
Subject: Re: Hot Swappable Kernels
To: black@zen.cypher.net (Ben Black)
Date: Wed, 6 Aug 1997 11:17:13 -0700 (MST)
Cc: jamil@counterintelligence.ml.org, msmith@atrad.adelaide.edu.au,
        terry@lambert.org, hackers@FreeBSD.ORG
In-Reply-To: <Pine.LNX.3.91.970806062554.27490D-100000@zen.cypher.net> from "Ben Black" at Aug 6, 97 06:26:39 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> systems like KeyKOS that store all kernel state outside the kernel could 
> theoretically do something like this.  if the state is stored inside the 
> kernel things get REALLY ugly if you want to try this.

This is not as big a problem as it seems.  There are only a few types
of state to worry about:

1)	Boot/probe state		<can be discarded>
2)	User state			<can be paged>
3)	Kernel state not in pager	<can be paged>
4)	Kernel state in pager (or SMP)	<permanent memory footprint>

There *are* things you can do, namely multistage replacement,
that would let you play around with state in #4 as well (including
the configuration state of the components which maintain configuration
state).  Mostly copy/execute, copy to replace copier, discard initial
and other tail-chasing games.  The permanent memory footprint should
be minimized, but there is definite value in things like runtime
vector replacement (yes, self-modifying kernel code) that this would
lock out.  I would prefer to see the stuff in area #4 loaded
contiguously and small, and would be willing to accept a reboot (or
the load of a complex module to do the replacement, which would not
be written on the initial pass) to deal with #4.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.