OSDev.org

ive just got basic IPC working between the current process the kernel and the servers e.g. file server in
my microkernel.
this is done by having a specific ID assigned to the kernel and server processes, so the
user process can identify where to send the msg.
I use the registers to pass the msg.

however im not sure on how to send messages between two user programs or between the driver process and the user program
as these i carnt hard code specfic ID's for.
is it best to still use the method above with out specific IDs, which means a msg could be sent to any process
even non-existing process,
or should i exclude user processes and drivers from using this method alltogether.
and only use pipes or another method to comunicate between user programs.

if i should used another method what would it be as currently L4 IPC keeps poping up
when im searching google and i am not sure how to implement that so dont want to use it
as it looks far to complicated for me.

the only way i think i could get the driver processes working is by getting them to register themselfs in a table
with all their calls and a specfic ID based on names rather than numbers. so once a user program puts a request to the
driver manager it looks up the name and then sends back the ID allocated to it back to the user process so the user
process and driver can then send msgs directly between each other.

if i have got this all wrong please say cos ill just go back to working on my other kernel until i can
get a better grasp of microkernels.

One possible answer is probably somewhere in between. You could use one specific ID for a server which can tell you all the other IDs, and then you'd ask that for the ID of the process you want to contact.

Similarly, several unix services store their process number in a file on disk so that a script can get its ID and shut it down again.

In essence, whether you want to use IPC, pipes, sockets or files, the common denominator is the fact that both ends share some sort of "routemap", telling how to get where they want to be.

When I tried writing a microkernel, I allowed apps and servers to register a name by which they could be accessed, like "com.exclaim.vfs" for the VFS and "com.exclaim.procmgr" for the process manager. For sending to drivers, the drivers would register themselves with the VFS which had a fixed name, so when a user app wanted to access a driver service it went through the VFS without having to know the driver PID (I also let messages be sent to a PID/TID). User apps were also allowed to register names through which they could communicate. Unfortunately I abandoned my microkernel because the design had various issues which meant the IPC was completely crippled when used in multi-threaded apps.

well, while in the process of writing that i was going to abandon my attempt at my
microkernel. due to a massive headache involving IPC, vm86 and ID's

i think i found the answer i was looking for when looking though the old blue illusion souce code
and a really old dos like kernel i written.

which is instead of passing the entire stack context into interrupt / system call handlers,
and do stack saving e.t.c the the handler rountines, but todo this in the interrupt stubs
instead.

means i have to re-write the kernel from the begining again but should solve most of my problems
and i should still be able to use my vm86 code with some very bad hacking at the code

well anyway i should find out in a couple of weeks if it works or not.

thanks for the replys tho, they will help when im redoing the IPC.