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.
Thread beginning with comment 474960
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by Kaj-de-Vos
by Neolander on Sun 29th May 2011 20:02 UTC in reply to "RE[2]: Comment by Kaj-de-Vos"
Neolander
Member since:
2010-03-08

Well, this looks like the beginning of an answer, so if you allow me...

In RPC, you assume that the remote end has a procedure you can call. That's a big assumption.

At the core, we have this: daemon process wants to inform the kernel that there's a range of things which it can do for other processes. The procedure/function abstraction sounded like the simplest one around the "things which it can do" concept to me.

To make it work, you assume that the remote procedure is written in the same programming language. That's a huge implementation "detail".

Hmmm... Can you mention a modern, serious programming language (joke languages like BF don't count) that does not have the concepts of a function or a pointer ? Because once the concepts are there, dealing with the switch from one language to another during a call is just a matter of gory implementation magic.

Messaging has a long history, really. These lessons were already learned in AmigaOS, BeOS, Syllable and new messaging systems such as 0MQ. You can also ask yourself what the most successful remote protocol does. Is HTTP/HTML RPC based?

I'd prefer it if we didn't put the notions of long story and success in there. DOS has a long story, Windows is successful. Does it mean that these are examples which everyone in the OS development community would like to follow ?

Edited 2011-05-29 20:05 UTC

Reply Parent Score: 1

RE[4]: Comment by Kaj-de-Vos
by Kaj-de-Vos on Sun 29th May 2011 20:21 in reply to "RE[3]: Comment by Kaj-de-Vos"
Kaj-de-Vos Member since:
2010-06-09

You keep defending your existing notions, instead of entertaining the notion I introduced that is apparently new to you. Do you agree that declarative data is at a higher abstraction level than a procedure call? Do you agree that not specifying an implementation language is simpler than specifying a specific language?

If you are not willing to look at common implementations, lessons from history become meaningless, either good or bad. Do you have experience with messaging in Amiga, BeOS, Syllable, microkernels, REBOL, enterprise messaging, or anything else?

Reply Parent Score: 1

RE[5]: Comment by Kaj-de-Vos
by Neolander on Sun 29th May 2011 20:38 in reply to "RE[4]: Comment by Kaj-de-Vos"
Neolander Member since:
2010-03-08

You keep defending your existing notions, instead of entertaining the notion I introduced that is apparently new to you.

I work this way. If you want to prove that your way of thinking is better than mine, you have to expose clearly what's wrong in my way of thinking. Alfman has been successfully doing this when defending the async model vs the threaded model, as such async has now more room in my IPC model.

Do you agree that declarative data is at a higher abstraction level than a procedure call?

Define declarative data, Google and Wikipedia have no idea what this is and I haven't either ;)

Do you agree that not specifying an implementation language is simpler than specifying a specific language?

Simpler? Oh, certainly not, if you consider the whole development cycle. The higher-level abstractions are, the more complicated working with them tends to be, as soon as you get away from the path drawn for you by the abstraction manufacturer and you have to think about what the abstraction actually is (which is, say, the case when implementing the abstraction)

As an example, when explaining sorting algorithms, it is common to draw some sketches that implicitly represent lists (packs of data with an "insert" operation). Now, try to visually represent sorting in an abstract storage area that may be as well a list or an array. How hard is that ?

As another example, which programming abstraction is easier to define to someone who has no programming knowledge : a function or an object ?

If you are not willing to look at common implementations, lessons from history become meaningless, either good or bad. Do you have experience with messaging in Amiga, BeOS, Syllable, microkernels, REBOL, enterprise messaging, or anything else?

I'm not sure what is it that you're calling messaging actually. Are you talking about the concept of processes communicating by sending data to each other (pipes), the idea of communicating over such a data link with a messaging protocol (like HTTP), ... ?

Edited 2011-05-29 20:48 UTC

Reply Parent Score: 1