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 475033
To read all comments associated with this story, please click here.
RE[7]: Comment by Kaj-de-Vos
by Neolander on Mon 30th May 2011 05:11 UTC in reply to "RE[6]: Comment by Kaj-de-Vos"
Member since:

Oh, alright, now I see better what is it going.

It would be a bit like using objects for making calls (yeah, yeah, I know, implementation details and stuff).

A malloc implementation could be described like...

//This is written in the PidginObject language
service Malloc [
....option AllocatedSize

And for the caller, it'd be like...

mymalloc = setup_service(Malloc)
mymalloc.setproperty(AllocatedSize = <whatever>)

...or if we're a messaging freak...

send_message(daemon, "run_service Malloc with option AllocatedSize = <whaterver>, option SaveWilly = no, etc...")

Actually, I plan to use something like that for UI description.

It has at least the following benefits :

-> You can indeed use language-agnostic headers (like XML or CSS). More precisely, you'd use headers written in your own language.
-> The order in which you put function parameters don't matter. That means that you can change one default parameter without redefining all the others "before" it, since there isn't such a concept
-> You can use a consistent data description language for services and UIs, settings, etc...

There are some tricks worth pointing out, though.

First, a significant header parsing overhead has to be here each time a functionality is called, not only when it is declared. This could be quite problematic for low-level stuff that has to be fast.

If you want to fully implement your own communication protocol, and not use those of an existing programming language, then you have to not only write the function prototypes in your new language, but also describe the data with it. Now this is a tricky one. In C, everything can be described in term of blocks of memory with integers inside and pointers. But there, if you want to do things cleanly using your own specifications, you need to create a syntax for arrays, a syntax for objects, a syntax for strings, a syntax for numbers, etc... one for each data abstraction which you want people to be able to use.

What this means is that you'll have to code a data translator that exactly as complex as a modern compiler, and have a great data conversion overhead, akin to that of having heterogeneous OSs written in different languages and running on different networks communicating over a network, except that it'll occur all the time, even when you remain on a local machine, running a single architecture, and doing calls between programs written in the same language. You do not optimize for the common case.

Astonishingly enough, this does not solve the compatibility problem.

The classical compatibility issue is that functions can gain parameters, but not change name, change the name of parameters, change the order of parameters, or lose parameters.

Here, the object replacing our functions cannot change name either (otherwise processes looking for that service using the old name won't find it). Parameters can't get a different name or disappear for the same reason (programs coded for an old version of the service wouldn't work). So basically, all we can do is change the orders in which parameters are written.

My question is, is it worth the performance hit of going back and forth an intermediate representation each time a call is made ? Is it worth the bloat and security risk of having a the translator around each time something as common as a procedure code is made ? Is it worth the extreme coding complexity of that translator, and the lost comfort of being able to use a large number of assumptions about the language being used ? How about rather writing function parameters in the right order the first time ?

Edited 2011-05-30 05:15 UTC

Reply Parent Score: 1