From owner-freebsd-stable Sat Apr 24 19:25:16 1999 Delivered-To: freebsd-stable@freebsd.org Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 4633015283 for ; Sat, 24 Apr 1999 19:24:52 -0700 (PDT) (envelope-from rgrimes@GndRsh.aac.dev.com) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.8/8.8.8) id TAA14953; Sat, 24 Apr 1999 19:24:22 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199904250224.TAA14953@GndRsh.aac.dev.com> Subject: Re: loading new kernel In-Reply-To: from Mike Meyer at "Apr 24, 99 05:56:29 pm" To: mwm@phone.net (Mike Meyer) Date: Sat, 24 Apr 1999 19:24:21 -0700 (PDT) Cc: stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. > > > On Sat, 24 Apr 1999, Allan wrote: > > > Date: Sat, 24 Apr 1999 17:42:23 -0700 (PDT) > > From: Allan > > To: Jim Cassata > > 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