Date: Sat, 24 Apr 1999 19:24:21 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: mwm@phone.net (Mike Meyer) Cc: stable@FreeBSD.ORG Subject: Re: loading new kernel Message-ID: <199904250224.TAA14953@GndRsh.aac.dev.com> In-Reply-To: <Pine.BSF.4.05.9904241752251.32471-100000@guru.phone.net> from Mike Meyer at "Apr 24, 99 05:56:29 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> This doesn't really belong here, but the right people read the list.
>
> There have been systems that could do this. The ones I know about all
> had multiple processors. Multics did the trick by migrating everything
> off of one processor, shutting it down, and bringing it up running the
> new kernel. Do that for each processor, and when you're done you've
> done a kernel upgrade. Tandems NonStop systems had multiple processors
> so it could have a CPU failure without stopping, and they also allowed
> OS upgrades to be installed without stopping (nuts, they allowed CPU
> upgrades to be installed without stopping), though I'm not sure of the
> details for that one.
>
> In other words, it's not a ridiculous idea. It does tend to be
> expensive to implement, though.
Having been part of a team that had to do this exact thing on a single
CPU machine I can say ``extreamly expensive'' to implement, and often
more economical options exists. Generally your doing things the hard
way if you thing you need this functionality. Both the Multics and
Tandem solutions above are the easier way.
The nuts and bolts of how to do it are rather complicated but here
is a quick summary:
a) Decide your going to do an implace kernel update
b) Clearly know what the userland/kernel interface changes
are and how this kernel upgrade would effect processes.
c) You must eliminate or prepare to upgrade in place any
userland code that is effected by b or the effected
processes are going to go zonk on you. (Hey, wants you
figure out the kernel part of this problem upgrade in
place userland code becomes trivial.
d) A special kernel mode thread is started that takes over at
this point and does the next few steps. This thread is run
in a special memory region that the current kernel had
setup and that the new kernel will release back to the
freepool when done.
e) All process contexts and internal state is brought to some
what of a quesent state and stored off into the special
kernels tasks data area. Note that the system actually
went dead to all interrupts when the special task takes
over so you don't have to do any locking or other ``hard''
stuff here.
f) The new kernel is blasted over the top of the old one.
g) Kernel structure/state and process context format conversions
are done that copy the old kernels idea of things into the
new kernels data structures. This was probably the toughest
part of the code to get working correctly, just think about
changing a simple flag possition in a status word of any
struct, when your head starts to explode for just trying to
track down all the places that might hit in kernel structures
you've got the picture. You've also got to handle the fact
that this new kernel is not going to run it's normal init
code to create vm maps and such, your migrate task has to
handle that by migrating the old vm maps into the new kernel
data structures. It also has to go find its little private
memory region in these maps and remark it as free, because
we be done and after the next step it won't matter.
h) Enable interrupts and let the lbolt clock drop us back into
normal scheduling.
Now realize you have to write step g specifically for both the
source and destination kernel, not something I image FreeBSD
would undertack. But for what we had to do it was done, but
then we had a rather controlled set of from/to pairs and only
had to write 5 of them :-).
We often short circuited non critical userland processes by
simply replacing the executing image and the killing the process
off and restarting it.
>
> <mike
>
> On Sat, 24 Apr 1999, Allan wrote:
>
> > Date: Sat, 24 Apr 1999 17:42:23 -0700 (PDT)
> > From: Allan <kosmos@blarg.net>
> > To: Jim Cassata <jim@web-ex.com>
> > Cc: stable@FreeBSD.ORG
> > Subject: Re: loading new kernel
> >
> > The more I think about this, the more ridiculous it sounds.
> > Of course, it would be a real neat trick if it could be done - kind of
> > like changing your sneakers while jogging..
> >
> > On Sat, 24 Apr 1999, Jim Cassata wrote:
> >
> > > hehehe, I had an employee who kept askin the powers that be if it could be
> > > implemented, and last I heard there was talk of implementing this,
> > > possibly in 4.0
> > >
> >
> > > On Fri, 23 Apr 1999, Allan wrote:
> > >
> > > > Does anyone know if it is possible to load and use a newly-built kernel
> > > > without shutting down the machine and restarting?
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-stable" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>
--
Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com
Accurate Automation, Inc. Reliable computers for FreeBSD
http://www.aai.dnsmgr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904250224.TAA14953>