[XCSSA] updating a kernel without rebooting

[xcssa@xcssa.org]

On Aug 17, 2006, at 1:29 PM, xcssa-admin@xcssa.org wrote:

> 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.

OS/9 was a Unix-like OS.  It was definitely not based on anything in  
CP/M.

In any case, OS/9 was very modular, in very much the way that Linux  
isn't.  Just about everything was a module, written in position- 
independent code (which was an important feature of the 6809 CPU).   
There was a kernel, but that was only one module in the boot image.   
All the drivers were separate modules unto themselves concatenated to  
the kernel to make the boot image, and the kernel scanned for and  
loaded them at boot time.  The equivalent in Linux is if you want to  
update a module, you can rmmod and then insmod the new module.  Even  
the executables were modules.

The problem is that the core kernel itself has to install itself in  
the system call vectors, of which there is only one set at the kernel  
level.  Also, drivers in the kernel must be compiled with  
dependencies on symbol locations in the kernel, even in a fullly- 
modular kernel.  You might be able to use a given binary module with,  
say, most versions of 2.4, but not 2.6.  And Linus has stated that he  
will not make any concessions to make that possible.

> 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.

The most important question is "Why?"  If the answer is "to keep my  
k3wl uptime!" then it's a waste of time.  If the answer is "high  
availablity", then the reply is "if you need HA so badly, why are you  
tinkering around hoping you can make something work, rather than  
paying money to someone who already has it working?"

  - Bruce -