[me17213]

I got to thinking (yes i know this is dangerous), I 'll admit I know very little about this stuff but....

Could it be possible for OSX to have two kernels, both exactly same.
kernel #1 does what the current kernel does now.
kernel #2 waits in the background in case kernel #1 poops out. in which case kernel #2 takes over, restarts kernel #1 to run as the background kernel. effectively switching positions.
The way I figure it, this would increase stability a ton. most crashes are caused by a kernel panic (if not all). the only way that could happen is if both were to crash at the same time.
someone please tell me if this is possible. and if it is would it take a lot for apple do it, if they did?

[serversurfer]

Umm, I kind of doubt it. If that kind of redundancy is required, you use two mirrored servers.

Why would you even think of this? Do you get a lot of panics? I've only had two since the Public Beta on my iBook 466SE. One was caused by a POORLY ported game (Glider Pro) and the other was when I plugged in my CyberShot before we had camera support. If your kernel panics on a regular basis, you should seriously consider re-installing. What are you doing to your poor box? That shouldn't be happening. It's why we went to UNIX in the first place. There are UNIX servers out there that haven't been restarted in years.

[me17213]

i've hardly ever had any kernel panics. In fact only 3 that I can remember (I've been running OSX since the first day it was released when my local apple reseller opened its doors). I was just putting this in because I thought it could add to the already great stability. And as far as I know, it would be the first to do something like this if apple did it.

[Smircle]

Originally posted by me17213:

I was just putting this in because I thought it could add to the already great stability. And as far as I know, it would be the first to do something like this if apple did it.

Very old Sun-Boxen had two CPUs, one tracing the other to help in case something should crash. So maybe your idea could be made to work. However, it would be a major technical effort since the kernel is the lowest interface to the hardware. Should it crash the other kernel could not be loaded from disk anymore.

And do not forget - if the kernel panics something has happened that really should not have happened. Chances are that the second kernel would go up in flames too.

Getting the running applications to talk to the new instead of the old kernel might be hard too

[Apocalypse]

Interesting concept but in my understanding of kernel architecture I don't think that it could be done. This is for one very simple reason: if the kernel knew how to recover, it wouldn't have crashed in the first place.

As far as some of the other details, it could almost work in that, if one kernel detected a panic or freeze on the other, it could over-write a copy of itself into the main kernel address space and continue where it had left off. The big issue with this is that this new instance wouldn't know what not to do to ensure that it doesn't do exactly what the other one did. The likely solution is that is would be initialized with all clean data stores so only hardware weirdness could make it crash. However, without the data used by the former instance, the entire OS would likely collapse since the new kernel would no nothing of what it was doing. This could be managed to only kill some user-level processes by keeping some sort of journal of system process progress but that would slow your system to a crawl through all the constant journalizing (this works for high-latency things like file systems but not low-latency things like memory).

Long story short: this system would require better fault-tolerance and robust behavior than just writing a kernel that never would crash in the first place.

As for the comment about the two CPU Sun systems, I think that is for hardware redundancy since you run into the same issue mentioned here with software redundancy that you are proposing. As far as I recall, those systems were used since the only time a Solaris system tends to crash is if there is a physical error in CPU operation (this is ridiculously improbable but has been known to happen). In those systems the two CPUs are always doing the same thing and their output is compared (likely through XOR operations in hardware) to ensure that there is no discrepancy between what they both think is correct.

Can anyone who really knows this stuff verify it for me?

Jeff.

[yukon]

interesting ideas. Possibly to be used when we have much more powerful hardware. Full data journaling will be standard then though.

[kangoo_boo]

hm
if i remember mach architecture good, there is a microkernel which gets it's intructions from the "kernel" "itself" (not proper terms
so when the kernel crashes the micro kernel is still running
you can be able to run some basic stuff on old rhapsody DP like halt reboot and stuff from keyboard with it

[cwagar]

Originally posted by me17213:
<STRONG>someone please tell me if this is possible. and if it is would it take a lot for apple do it, if they did?</STRONG>

In a larger OS sense, the kernel is responsible for just a few tasks... memory management and process prioritization.(*)

In order to get to a high-availability architecture (which is basically what you describe), you would implement two processors, each running a copy of the kernel. There would be some serious double-commit type locking in place for each action the kernel took in order to ensure that both kernels were in sync constantly. And both kernels would need to be able to intercept the communications from the running processes (applications).

Furthermore, it would require some sort of arbitration or shared access to other things like memory, video, busses, etc.

It's not cheap, and it usually involves some very high end hardware. (e.g. the old Tandem computers, etc.).

Clayton

(*) larger sense = all Unix'es, not just the Mach implementation of a kernel.