[XCSSA] updating a kernel without rebooting

[xcssa@xcssa.org]

I remember the days of OS/9 - not the Apple O/S but the C/PM-based O/S -
when you needed to have the entire boot sequence on a 180 MB S/S floppy
disk.  In those days, you would build your "boot" with a utility called
"cobbler."  (Cobblers make new boots, right?)  If I remember correctly
there was only the tiniest bit of code comprising the nugget of the
kernel and the rest was the specific commands you reckoned you'd need.

Commands such as "cd", "dir", etc. were all groups of functions which
would be included as needed in the build.  It was then the custom to
have different "boots" for different applications.  The reason I say
this is that I think, at its heart, the unix kernel is functionally the
same in that the kernel is actually a collection of modules, albeit much
more complex than the aforementioned 8-bit O/S.

That said, I think it would be entirely feasible to create a kernel
"patch" which would only contain the actual changes from the previous
version.  A well-written utility could then clear the old sub-module
from RAM and link to the address space of the new one.  Remember the old
"peek" and "poke" commands from Apple DOS?  The only conflicts would be
in modules presently running which could then be updated during pauses
as if an interrupt was called.

My guess is that kernel upgrades are really changes to the sub-modules.
 Or at least it seems that way when I read change logs to kernel
updates.  Am I barking up the wrong tree or would that even be possible?
 Is the unix kernel internally designed the same way?

Of course no such system exists but to my untrained mind it seems
entirely feasible.
Dan Coit

xcssa-admin@xcssa.org wrote:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0107.1/0313.html
> 
> I seem to remember seeing something around kernel 2.4 about it but it was
> experimental and of course you had to have everything setup before your
> last
> boot for it to work.
> 
> A quick google didn't yield more than that old kernel thread.  I'll look
> deeper after I have some coffee.
> 
> --anton
> 
> On 8/17/06, xcssa-admin@xcssa.org <xcssa-admin@xcssa.org> wrote:
>>
>> Hey, I had a question the other day that isn't trivial to answer.  Let
>> me run it by you.
>>
>> The main reason Unix systems go down, assuming you have a UPS, is for
>> kernel upgrades.  What would it take to upgrade a kernel _without_
>> rebooting?  I may ask this on the linux kernel mailing list at some
>> point, but I'd see if anyone locally had a handle on this level of
>> detail.
>>
>> Obviously we can't just flush everything and start running a new
>> kernel from the beginning of the boot process; that would be a lot of
>> work for the same result as rebooting (modulo a minute of time or so).
>> But clearly it's okay to, say, flush pages from the buffer cache.
>> What counts is that processes which were running continue to run
>> without restart, and maybe that network connections survive (modulo
>> any timeouts).  Everything else is gravy.
>>
>> Let the brainstorming begin!  And be quick about it, I want an
>> implementation by the weekend. ;-)  I bet Bruce Schneier could do
>> it.... http://geekz.co.uk/schneierfacts/
>>
>> Anyway, if this could be done, Unix could brag _even more_ about
>> uptimes.  They'd be damn near forever, and that would really tick
>> Redmond off, which would make it all worthwhile, don't you think?
>> -- 
>> "If you're not part of the solution, you're part of the precipitate."
>> Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
>> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484
>> _______________________________________________
>> XCSSA mailing list
>> XCSSA@xcssa.org
>> http://xcssa.org/mailman/listinfo/xcssa
>>
> 
> 
>