Date: Wed, 6 Aug 1997 11:17:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: black@zen.cypher.net (Ben Black) Cc: jamil@counterintelligence.ml.org, msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Hot Swappable Kernels Message-ID: <199708061817.LAA14438@phaeton.artisoft.com> In-Reply-To: <Pine.LNX.3.91.970806062554.27490D-100000@zen.cypher.net> from "Ben Black" at Aug 6, 97 06:26:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708061817.LAA14438>