i'm not sure whether it is possible but with intel's IOmap and IOPL properties plus a good dynamic linking engine, it should be possible.
Kernel Model
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Kernel Model
imho, the best approach would be to make the module ignorant of what ring it is run in, so that you can keep the module at DPL3 if you really fear it to misbehave or promote it if it appears to work nicely
i'm not sure whether it is possible but with intel's IOmap and IOPL properties plus a good dynamic linking engine, it should be possible.
i'm not sure whether it is possible but with intel's IOmap and IOPL properties plus a good dynamic linking engine, it should be possible.
-
nullify
Re:Kernel Model
It seems that the OpenBeOS guys are doing this with their network stack, with the whole issue on having BONE or trying to mimic R5 as closely as possible first. Wouldn't this make the system less portable, though? Unless other systems also have equivilants of IO bitmap and IOPL...Pype.Clicker wrote:imho, the best approach would be to make the module ignorant of what ring it is run in, so that you can keep the module at DPL3 if you really fear it to misbehave or promote it if it appears to work nicely
i'm not sure whether it is possible but with intel's IOmap and IOPL properties plus a good dynamic linking engine, it should be possible.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Kernel Model
most non-IA systems i know have memory-mapped I/O exclusively (this is at least the case for SPARC and PPC, afaik). In this case, no IOmap is even needed: you just control who access what hardware by playing on the memory mapping (just as you would control who access the video buffer on a PC)
-
mystran
Re:Kernel Model
Ok, I'm new here.
Anyhow, my hobby project relies on a simple microkernel, since the whole system aims to be simple.
I only implement threads, virtual memory and IPC in the kernel, rest of the system communicating with IPC.
The reason for doing microkernel was basicly to have as little code as possible that can easily crash the system, and to make it easier to develop one piece at a time.
I could probably claim to have a nanokernel with kernel mode servers as well, since the user-space memory manager is separate from the rest of the kernel, so there's basicly a soft-realtime scheduler and some glue-code in the core kernel, but since I honestly don't know what exactly is a nanokernel, I'll stick to the term "microkernel".
Anyhow, my hobby project relies on a simple microkernel, since the whole system aims to be simple.
I only implement threads, virtual memory and IPC in the kernel, rest of the system communicating with IPC.
The reason for doing microkernel was basicly to have as little code as possible that can easily crash the system, and to make it easier to develop one piece at a time.
I could probably claim to have a nanokernel with kernel mode servers as well, since the user-space memory manager is separate from the rest of the kernel, so there's basicly a soft-realtime scheduler and some glue-code in the core kernel, but since I honestly don't know what exactly is a nanokernel, I'll stick to the term "microkernel".