The OS-periment: RPC-Based Daemon Model Goes 'RC'
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.
E-mail Print r 1   92 Comment(s) http://osne.ws/j4t
Permalink for comment 474925
To read all comments associated with this story, please click here.
RE: RPC considered harmful
by Neolander on Sun 29th May 2011 12:52 UTC in reply to "RPC considered harmful"
Neolander
Member since:
2010-03-08

You asked for criticism, so I'll be negative: RPC is a bad concept to base an entire OS on. It's inherently tied to the implementation language

Why couldn't wrappers be used? Most Unices have a system API that's linked to C concepts at the core, that doesn't prevent C++ or Python wrappers from being used by people who prefer those languages, at the cost of a small performance hit.

and to the implementation details of the services.

Again, why has it to be the case? A good interface can be standard without revealing implementation details. If I say that my memory allocator is called using the malloc(uint parameter) function, how does it prevent me from changing the memory allocator later ?

That makes it difficult to port,

Define port. What do you want to port where?

hard to keep compatible with itself over time,

Unless I miss something, it's not harder than having a library keep a consistent interface over time. Which is, again, a matter of having the library interface not depend on the implementation details. Why should it be so hard?

and thus hard to keep compatible with different versions of the services.

Not if people don't break the interface every morning.

The abstraction level of RPC interfaces is too low.

Why? If the interface of C-style dynamic libraries is enough, how can the RPC interface, which is just a nonblocking and cross-process variant of it in the end, be different?

To solve these problems, you need a messaging specification at a higher abstraction level, through declarative data specification.

Well, I wait for answers to the questions above before asking for more details about your suggested answer.

Reply Parent Score: 1