thewrongchristian wrote:
bloodline wrote:
moonchild wrote:
The main problem with microkernels is performance. However, they don't scale any worse than traditional kernels; so I think they would work well for your purposes.
Obviously I’m not an expert, but when I read the papers regarding poor performance of the micro kernel design vs a monolithic design, they focus on problems caused by having a single CPU. When you can have when servers and tasks can genuinely run concurrently (i.e. on an SMP Machine), these performance issues become negligible, and more than this, the design of the micro kernel lends itself to multiple threads of concurrent execution.
Aren't performance "problems" with early micro-kernels basically down to the fact they operated synchronously? That way, each message is guaranteed to result in a context switch, and all that that implies.
Even with asynchronous messaging, the problem then becomes one of implementing compatible APIs on top that are inherently synchronous, such as POSIX. But this translation can also be a benefit, as it gives scope to provide a more flexible user thread model if the OS interface is inherently asynchronous, so making N:M threading models not only easier to implement, but also natural.
And of course, when operating in messages, it doesn't matter where the message consumer lives, so it can be a kernel thread in the case of a hybrid kernel, or a user thread in the case of a purer micro-kernel. But in either case, you can scale across multiple CPUs to achieve performance through concurrency.
Doesn't this basically describe managarm?
Yeah, that makes sense. I read an article a couple days ago about the only thing prevent computers with 100000+ nodes is POSIX I/O. Basically, it was saying POSIX I/O scales horribly, and I have to agree. Anyway, I think I have an architectural plan for my kernel, tell me any issues you see in it
So, my idea is an "everything is a message port idea". I'm going to revive the old Mach port idea, and message ports won't necessarily represent a message queue. It could represent something like a semaphore, a process control block, any resource inside the kernel is going to be a message port. A port representing one of these objects doesn't context switch, so it contains hardcoded function pointers called message handlers. The message manager takes the message ID, and uses that to find this messages messages handler, passing the message packet as a parameter. Now the object we sent the message to acts upon it, and returns, all without a context switch. Those are user mode to kernel mode messages. Then there are user mode to user mode messages, which work in the normal way. What do you say about that?