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 475373
To read all comments associated with this story, please click here.
RE[16]: Comment by Kaj-de-Vos
by xiaokj on Tue 31st May 2011 23:05 UTC in reply to "RE[15]: Comment by Kaj-de-Vos"
xiaokj
Member since:
2005-06-30

More generally, I have been for some time under the impression that in this topic, we are talking about very similar things with a very similar set of advantages and drawbacks even though we don't know it yet.

*laughs*

Same here. |0|
(in-joke, somebody read that as lol)

I broadcast a version number ALONG WITH a prototype, doesn't the whole thing qualify as a spec sheet ?

Still too crude, since you can have minor behavioural changes. Mathematica is one of such examples -- each update, it will tweak some commands a little bit, and even though the parameters are the exact same, the functionality may be drastically changed such that automated updating is impossible.

Version numbers do little, especially if you run a gap of a few version numbers, depending upon the scale of the problem (determined mainly by the coder, really).

I am really more interested in compatible breakage -- for example, a previously provided functionality A is now replaced by B and C whereby most cases go for B, and some go to C under some conditions. If automation can still be of use, I do not see why the original code needs to be recompiled -- the slight performance hit should be okay for most. Even after a few more rounds, I see no problem. It really should be the translator's job, to me (the translator will kill me, hehe).

Come to think of it, this is really abuse of translation. Some things just cannot be handled that way. For example, the old C string format had been changed drastically because of massive security holes. Such that, we realised, that one of the tokens is completely dangerous and it is no longer even allowed (let alone support)! Most new implementations will just "politely segfault" if you tried to use it. (I'm talking about the one that outputs the number of bytes written into a memory address thing). I don't know how the translator should handle this: Should it barf (as is currently done), or should it silently drop the message? Or something in between? This is a huge thing to judge, because of the myriad implications.

Sigh.

Reply Parent Score: 2