OSDev.org

Seems I can't avoid having processes able to access kernel calls. Who knows maybe I'll think of something

You could trap unprivileged applications doing system calls, and instead of executing the call perform synchronous IPC with a governing process

That means going into the kernel, right?

Just create a loop between two serial ports with a null modem cable and give the processes some IO privledges..... IPC without kernel interaction! </joke>

And who gave the processes the io privileges? The kernel! This is just like the memory sharing outlined above, only funnier.

And also this was supposed to be for low-privilege processes, they can't have io port access.

So possibly the only thing I need to be implemented in the kernel is IPC?

IPC and scheduling. Otherwise there won't be any processes to do the IPC.

Scheduling can be handled outside the kernel. Process switching must be done by the kernel of course, for changing page tables and the like.


JAL

Why not give the process a shared page that it can use to communicate with the IPC server when the process is spawned?

You could do that, but the IPC server would have to continously keep checking the pages of all processes to see if something happened in there. Does it sound efficient?

How about a page every process uses that acts like a queue (with a lock of course so only one process can use it (or a section of it) at a time)? And maybe a bit somewhere that each process is assigned, and when it's set it means there is something waiting on the queue (this bit could also be used to awake sleeping processes).

I'm probably far oversimplifying it (I haven't really thought about it much at all) but it's one possibility of how you could do IPC without system calls. The disadvantage of this is mostly performance related. The queue could be locked right before a context switch and therefore every other process trying to communicate will essentially be stalled for a time slice each (this could be fixed with some research into locking algorithms and having a dynamic number of locks or something). Also, there's no way to have block-and-sending that will instantly task switch while sending the message at the same time (e.g. imagine a game (the only active process) sending an graphics command to the graphics server, the game will sleep while the graphics server awakens and a message is send to the graphics server and switch to the graphics server (if the only process awake) - all in one atomic call), I guess you could get around this with firing the timer several times faster than the time slice (though too rapidly and then a noticeable percentage of your CPU cycles will be spent inside your handler) to check if the process's sleep bit is turned on or queue several messages before deciding to sleep.

This might only be viable if we had an interrupt-less, exception-less (and in all other ways impossible to implement calls) system.

If it's on a real time system then it could be a way to guarantee that a process has exactly the right amount of processing time (no cycles stolen behind the scene because an end programmer doesn't have to make any guess work how long a system call takes (cycles to enter interrupt + interrupt handling code) which they don't have any control over). This is really the only practical advantage I see.

Do I think it's worth it? No. Do I think it's possible? Yes.

yeah, still going over everything.

Errmm... and how would you obtain the lock? *cough*


JAL

If you have shared memory you can implement spinlocks with 'lock bts'. It will chew up most of your processor time, but doing IPC without system calls isn't exactly great for performance to begin with.

no more without system calls! I'm just going to limit the calls. Anyway, I now have a basic kernel set up, though I'm not getting into the coding until the design is complete.