Micro Kernels and User Land Drivers

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
elaverick

Micro Kernels and User Land Drivers

Post by elaverick »

Ok I'm confused (again)...
Everyone says the Micro/Nano Kernels are safer than Monolithic Kernels as drivers are run in User Land and so can't cause fatal errors to the rest of the Kernel.
However what I don't understand is that if you need a driver to access low level hardware stuff (interrupts etc) then it's going to need access to parts of the Kernel. The fastest way it seems is to use shared memory, but it sounds as though that would require mapping part of the Kernels memory space back into the requesting User Land driver, surely then it's just as crashable as a Kernel based driver?
Also how do you allow User Land drivers to access Kernel functions through shared memory? The compiler will want to know something about these functions at compile time won't it?

Sorry if this sounds as if I gibbering, but I've been reading through multiple topics today after finally getting my HH kernel to compile correctly for the first time and I think my brain has turned to mush...
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:Micro Kernels and User Land Drivers

Post by Candy »

The main separation is that if your driver mucks up something that you can recover from, you can recover from it. That does not go for crashing a hardware device but that does go for memory allocation. If a userland driver screws up the memory so badly that malloc dereferences a null pointer, you can kill the driver knowing the kernel memory isn't bothered. You can also keep track of the ports the driver had in use and free them again, etc. If it controlled a scsi device that crashed because of some bad opcode (or good even - seen that happen) you still can't revive the device.
Post Reply