Microkernel and driver resource access.

[turdus]

Why messages to kernel? I understand that we use messages to services in user space but to the kernel normal call gates can be used. I know some kernels use messages as kernel interface but not really understood the benefit.

Clear design. Small code. Consistent API. Technically speaking there's no message passing involved when communicating with kernel (message passed in registers), but from userspace point of view it's not noticeable. This is a hack to fix performance issues with microkernels and to avoid api hell of monolithic kernels. I have a special service (destination 0) which is not a real service with it's own thread, instead it's mapped in all address space, and performs like a monolithic kernel api. First 255 destination are reserved for services, like:
0-kernel services (mapped in)
1-filesystem services (separate thread)
2-networking services (separate thread)
...etc.
Init (first real userspace app) has the destination id of 256.

I have only 4 system calls as my kernel api to deal with messages (and won't change):
- async recv
- async send
- sync send (async send+async recv)
- sync recv (async recv+async send)
The 3rd is the remote procedure call, and the last is it's counterpart dispatcher.

[gerryg400]

- sync recv (async recv+async send)

I understand the first 3 but how does this one work ?

[turdus]

- sync recv (async recv+async send)

I understand the first 3 but how does this one work ?

Simple. The task is running an infinite loop calling dispatch syscall in it's main(), and it also has public methods. When the message queue is empty, the task won't be scheduled. If there's a message waiting, the following steps are taken:
1. from the message destination field I got a method id
2. the linkage table in object file is consulted and entry point returned for that method (or error if it's not public or belongs to a different class)
3. the user stack is altered to reflect a method call, and IP is modified to the entry point from step 2.
4. the thread is awaken, and after scheduled, the method's code is executed.
5. when the method is returned, a response message (with the return values) is constructed and sent to the caller thread.
(Caller thread is executing an RPC, so it'll be after send waiting for receive results)
This is how normal remote calls work, if destination is thread id 0, a totally different way is used.