jal wrote:
Interesting idea, but to communicate, you must request some entity for the communication. And you must, by definition, communicate with that entity in a special way, to avoid a chicken and egg situation. I would call that entity the kernel. Also, you'd want only a limited number of processes in kernel space (as opposed to user space). Your 'core services' may run in kernel space, and thus I would consider them the kernel together.
I think you're not quite getting the SIP concept. In a SIP based architecture, all tasks run in kernel mode, but they're isolated from each other using software verification and type-safe code. They're all running in kernel mode according to the processor, but their code can't interfere with each other or they won't be loaded. In my kernel design, the core services are isolated from each other just like user tasks, but they are more privileged and can execute certain special instructions. As an example, device driver tasks would be running in their own tasks that are isolated from everyone else, but they would be given permission to read and write only to certain I/O ports that they needed to perform their job.
You're right in that there needs to be a system of communication between tasks, and that has traditionally been performed by the kernel. The chicken and egg syndrome comes in because of the hardware isolation that most operating systems use, but by using SIPs I can move IPC to a separate "Communication Manager" task that can be called by a normal task, but is still isolated from the rest of the operating system. I'm hoping that this system of least privilege in the kernel will help improve security (you can't just do anything if you take over one of the core services), stability (crashes and bugs are isolated) and make it a lot easier to write (a few separate services instead of one giant kernel).
I'm writing a paper on the design, and I'm wondering if anyone would be interested in me posting a link to it.
~~ FutureDomain ~~