Dual Kernel System [How, Cons, Pros]

[coolcoolm]

Is it possible to have two kernels running at the same time on a dual core processor? if it can be done how would I go about doing it?

The Attachment is what I intend to do.
The User-Interface does all the programs and screen drawing
The Hardware-Interface does everything to do with the hardware like saving files, opening files

[Brendan]

Hi,

Is it possible to have two kernels running at the same time on a dual core processor?

Yes.

The problem is that it doesn't sound very efficient. For example, you might have a computer with a pair of quad core CPUs (with hyper-threading), and you might have many threads trying to use the GUI at the same time (or many threads trying to do I/O at the same time), and out of the 16 logical CPUs you'd be trying to do everything with only one of the CPUs.

if it can be done how would I go about doing it?

I'm not sure where the "hard part" is...

Your boot code would need to load both kernels into memory; and you'd need to decide how they share common resources and how the kernel's communicate with each other. For a simple example, would both kernels share all available free pages, or would they be given a fixed amount of free pages each during boot?


Cheers,

Brendan

[gravaera]

This is radical if nothing else. A good design concept, too. Please, if you intend to go through with this, by all means, use this topic as a sort of update of progress if you will. If nothing else, it would be something to add to the Wiki, once enough evidence of possibility of actualization is available.

-Good luck
gravaera

[Troy Martin]

Interesting idea, it could work really well if properly maintained. The only problems I see with it are the difficulty in maintaining it, debugging, and also keeping things in sync. You don't want one kernel to write something while the other's writing it or doing something with it, and so forth.

[Love4Boobies]

What would be the point in doing it this way? Do you actually see any advantages? If yes, point them out - you always need to do that when coming up with a new design. TBH I only see disadvantages. Not to mention that running the GUI in kernel mode is a bit odd and unstable (despite the fact that Microsoft have been doing it this way for years).

[Combuster]

This is radical if nothing else. A good design concept, too.

Maybe except for the fact that you have twice the amount of privileged code, all of which can crash double the amount kernels at the same time...

[MasterLee]

It maybe if you have multiple cpu cores with different characteristics. For example one lays near and the graphic system and another near the keyboard and IDE controller. Especially when you must route through each other to access the other part.

[geppyfx]

I am not sure how much advantage there is to run 2 entirely different kernels for as long as they don't use some common interface. Competing for the resources will be inevitable. If you decide to strictly separate functions betw different CPUs then one CPU could be standing still while the other doing 101% workload.

Running exactly the same kernel on 2 similar CPUs is quite easy. In the case of x64 arch you would choose single register to be the pointer to the data section in that CPU. All mem addrs are acquired thru that register. You can have per cpu scheduler,device drivers... while executing exactly the same code on all CPUs. Some locking necessary, how much - depends on design.
If you choose to have all CPUs use same linear addrs for data then its possible to get away without register, but you could be loosing in performance if cache associativity exhaust itself.

I am wondering if you want to do someting similar to Barrelfish

[gravaera]

This is radical if nothing else. A good design concept, too.

Maybe except for the fact that you have twice the amount of privileged code, all of which can crash double the amount kernels at the same time...

...? That may not necessarily be a bad thing: if he's an Eleanore Semaphore type, he'll be likely to spend a very long time in creating subsystems to harmonize everything, and in the end, may even make a stronger kernel design after everything:

Imagine having SEHs (Structured Exception Handlers) within each kernel which are able to diagnose problems in the other, and automatically respond; Shared pages maintain the relevant necessary links, and a concept of each kernel having its own Kernel-Local data, and both sharing a certain amount of carefully planned out, carefully constructed synchronization pages, etc. Making each kernel generally independent of the other could actually, rather than make having two major systems in Ring 0 a problem, make it a HUGE benefit.

It would all depend on how the OP implements it.

EDIT: I can't speak for him/her, but if it were me, I would spend about the first 60% of my development time devising small, fast, memory efficient methods of ensuring that everything stays in as perfect a harmonious state as possible.

[Love4Boobies]

I would have to disagree. Independent or not, they're not independent. The reason for that is that they are both running at ring 0. I still only see disadvantages - it's not a matter of implementation it's just a bad design. A more interesting somewhat related design is the cache kernel where you have application kernels running on top of the cache kernel - which is mainly an exokernel. NT is porbably a bit related to cache kernels as well - although I know it's not. The effect of having multiple subsystems is the same as having multiple application kernels though.

[NickJohnson]

I don't see what the difference is between having two kernels and one kernel is anyway. Saying that you have two kernels is the same thing as having one kernel with two discrete subsystems - it's all in the same place, with the same privileges. If you have a preemptible kernel, you don't have to worry about the use of one resource (graphics) stopping the use of another resource (disk), and if it's a microkernel, drivers can't step on each other easily. You can have the same kernel running on any number of processors too - it's not much of a conceptual leap from having the same kernel mapped in the address spaces of multiple processes.

[dosfan]

Interesting concept. I've thought about similar designs in the past.

Psssst. Isn't this like Barrelfish??

Edit: ....the multikernel part

[coolcoolm]

the main attraction to on this is if its written right it would be able to restart each other if one crashes and should be minimal information loss also i think it would be possible to increment a security system on each kernel that would have permissions and such. a side effect i thought about would be that image rendering should be faster, along with file operations since in theory the operating kernel wouldn't have to deal with the file system itself.

it should work in theory but nothing ever works out how you plan. but anyway i'll show yall some screen shots if i get it working somewhat


edit: while I'm thinking about it
the only part of the hardware the user-interface is going to be able to access is just going to be the screen & speakers i forgot to clarify that in the original post
also the two kernels are supposed to operate separately (thats the reason i'm writing them as two separate kernels)

[NickJohnson]

the main attraction to on this is if its written right it would be able to restart each other if one crashes and should be minimal information loss also i think it would be possible to increment a security system on each kernel that would have permissions and such.

The thing is, you will always need some resource sharing between the kernels. One important example is a physical memory manager - both kernels will need it, especially if they want to "fix" each other. Another is that security system: you will probably need to keep track of processes' permissions to implement one, and that requires some sort of centralized table.

A "self-repairing" kernel is very possible in a microkernel design, which can be done exclusively inside of kernelspace (although it is not traditional to do so). That's actually a large part of MINIX 3's design. Either way, it is hard to repair a running kernel/driver, and you will always get information loss. The easier and more correct solution is to *fix the broken code* instead of trying to cope with it at runtime.

a side effect i thought about would be that image rendering should be faster, along with file operations since in theory the operating kernel wouldn't have to deal with the file system itself.

If you build a kernel properly, and make it preemptible, you won't have problems with drivers tying each other up, which would be as effective as having (at least) one kernel per driver in your design. Plus, centering the entire design around a theory about what will improve latencies is definitely a type of premature optimization.

[Love4Boobies]

I thought MINIX 3 only restarts drivers if they don't respond via the communication channel or something like that. However recovering from faults in the kernel is entirely possible for any design - for instance look at this paper for an example on how to do that using a strategy called recovery domains. Double kernel means double trouble.

but anyway i'll show yall some screen shots if i get it working somewhat

Why? We can't see how great the concept is through screenshots. You can draw whatever you want on the screen - have the best possible GUI, it doesn't make the dual kernel concept sound.