Linked by Hadrien Grasland on Sun 29th May 2011 09:42 UTC
OSNews, Generic OSes It's funny how trying to have a consistent system design makes you constantly jump from one area of the designed OS to another. I initially just tried to implement interrupt handling, and now I'm cleaning up the design of an RPC-based daemon model, which will be used to implement interrupt handlers, along with most other system services. Anyway, now that I get to something I'm personally satisfied with, I wanted to ask everyone who's interested to check that design and tell me if anything in it sounds like a bad idea to them in the short or long run. That's because this is a core part of this OS' design, and I'm really not interested in core design mistakes emerging in a few years if I can fix them now. Many thanks in advance.
Permalink for comment 475036
To read all comments associated with this story, please click here.
RE[2]: RPC considered harmful
by Neolander on Mon 30th May 2011 05:48 UTC in reply to "RE: RPC considered harmful"
Member since:

I probably shouldn't use the "RPC" term, you too got confused into thinking that I was talking about blocking calls, while I am in fact doing nonblocking calls.

Once you have a nonblocking call interface, you can trivially implement a blocking call interface on top of it. I simply choose not to do it because I don't want to favor this kind of dirty practices if I can avoid to.

As for RPC being too high level, well... I'm tempted to say that pipes are too low level.

Don't get me wrong, pipes are great for programs of the "streaming" kind, which have an input data stream, process it, and return results in an output data stream. That's why I have them. But most tasks of a system API do not belong to the data stream processing family, and are more about executing a stream of instructions.

In that case, pipes are too low-level, because they are fundamentally a transportation medium for integer data, not instructions. If you want to send instructions across a pipe, you have to use a communication protocol on top of the pipe layer in order to get an instruction representation, so what you have is user-mode RPC implemented on top of the pipe IPC primitive.

I personally think that if an IPC primitive is to be very frequently used, it's better to implement it directly in the kernel (or at least parts of it), due to the extra control it gives over the communication process. The kernel executes trusted code, but library code can be compromised.

Reply Parent Score: 1