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 474955
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by Kaj-de-Vos
by Alfman on Sun 29th May 2011 19:17 UTC in reply to "Comment by Kaj-de-Vos"
Alfman
Member since:
2011-01-28

Kaj-de-Vos,

"Leaking of implementation details is detrimental to interfacing with other hardware architectures"

I understand all your initial criticisms, however I'm curious how an RPC interface leads to leaking of implementation details?

Corba interfaces are completely portable across many languages/platforms, including scripting languages.

Heck, just using corba itself would provide instant RPC compatibility with almost all serious languages out there.

If corba is too heavy weight to use in the OS, one could still provide an OS binding for it - that might even be a novel feature for the OS.

Reply Parent Score: 2

RE[2]: Comment by Kaj-de-Vos
by Neolander on Sun 29th May 2011 19:33 in reply to "RE: Comment by Kaj-de-Vos"
Neolander Member since:
2010-03-08

If you understood his criticism, could you please answer my questions ? Or at least some of them ? I still don't get what his problem is myself, and it seems that he isn't interested in answering...

Edited 2011-05-29 19:37 UTC

Reply Parent Score: 1

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

I will, but I got the feeling that you are not ready to accept the criticism you asked for. The overarching problem here is that most of the world is in mental models that consist of code instead of data, and thus code calls instead of semantic interchange, and thus implementation details of how to do something, instead of what to do. It turns out to be hard for people to switch models, so I have stopped trying over time.

Reply Parent Score: 1

RE[2]: Comment by Kaj-de-Vos
by Kaj-de-Vos on Sun 29th May 2011 19:38 in reply to "RE: Comment by Kaj-de-Vos"
Kaj-de-Vos Member since:
2010-06-09

In RPC, you assume that the remote end has a procedure you can call. That's a big assumption. To make it work, you assume that the remote procedure is written in the same programming language. That's a huge implementation "detail".

Remote objects are just an object oriented extension of the RPC concept. They were en vogue in the nineties, when everybody switched to remote architectures. This was when CORBA and other such methods were found to be too cumbersome.

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?

Reply Parent Score: 1

RE[3]: Comment by Kaj-de-Vos
by Neolander on Sun 29th May 2011 20:02 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[3]: Comment by Kaj-de-Vos
by Alfman on Sun 29th May 2011 20:20 in reply to "RE[2]: Comment by Kaj-de-Vos"
Alfman Member since:
2011-01-28

"In RPC, you assume that the remote end has a procedure you can call."

Well, that's a given, but we're talking semantics here. Whether your talking about dos interrupts, linux syscalls, vector calls, we're still technically calling a "procedure".

I guess you are referring to different mechanisms for parameter passing?

It's true there are different incompatible types (for example __cdelc or __stdcall), and these may even have subtle differences from platform to platform (passing floating point values in ST0 instead of stack). But these are strictly binary differences, all models are compatible at a source level - I just need to recompile.

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

Why did you ignore my counter example? In any case, this is no different than windows or linux being written around C callers.

"That's a huge implementation 'detail'."

Exactly, it's an implementation detail which end users rarely if ever need to concern themselves with. People don't need to know the calling conventions of their platforms to be able to write code.

Reply Parent Score: 2