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 475465
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[22]: Comment by Kaj-de-Vos
by xiaokj on Wed 1st Jun 2011 15:52 UTC in reply to "RE[21]: Comment by Kaj-de-Vos"
xiaokj
Member since:
2005-06-30

Nice to hear that you find it interesting too.

Actually, despite a lack of battle myself, there are quite a lot of war history on this front. For example, from Raymond Chen's experience being at the forefront of Windows development, compatibility is a huge thing. It is one of the deciding factors in the popularity game, which then influences the amount of help/resources you get.

For example, in the Win3.11->Win95 split, there is a altogether new API coming in. All Win95 programs need to work with it, or else. But the new API has yet to be written. The way out was a massive effort to translate all the old calls to the new one, so that Win95 came out supporting all the old stuff. (The fact that it had a real DOS in the hood makes it a lot easier, but still. Things like the SimCity incident is one for all to remember.)

On the other hand, it is also clear having too much compatibility kludges in the system proper is bad. Hence why I propose to put it into translator wrappers, so that there is sufficient glue to keep the system running without recompilation, without the excess for the "everything new and works together" normal case. The fact that it does automatically penalise un-recompiled code by the translation overhead is, to me, a good thing, despite being a definite pain for real world maintenance/performance.

Of course, it is nice that you also note the clear preference on evolutionary computing from here. Funnily, from whatever little of LISP experience I have, I actually like the "do it right the first time" approach better myself. It is kind of a mix, really -- if you like "do it right", then it is important to force yourself to take some evolutionary precautions too, whereas if you like the "implement it now", then it is also imperative to give your designs a bit of thought too. And I digress into philosophy again.

PS: It is interesting to also see Alfman joining our conversation, although he has less to say to me. And how it actually developed from Kaj-de-Vos' one small vague comment.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

Actually, despite a lack of battle myself, there are quite a lot of war history on this front. For example, from Raymond Chen's experience being at the forefront of Windows development, compatibility is a huge thing. It is one of the deciding factors in the popularity game, which then influences the amount of help/resources you get.

I fully agree with that. Compatibility is important, because it provides developers the invaluable ability to write some software once and stop worrying about it once it has reached a stable and bug-free state, instead of having to follow API versions and constantly rewrite things.

On the other hand, it is also clear having too much compatibility kludges in the system proper is bad. Hence why I propose to put it into translator wrappers, so that there is sufficient glue to keep the system running without recompilation, without the excess for the "everything new and works together" normal case. The fact that it does automatically penalise un-recompiled code by the translation overhead is, to me, a good thing, despite being a definite pain for real world maintenance/performance.

I'd argue that nothing prevents system API manufacturers from putting all compatibility kludges in a separate code module, separating them from the rest. After all, you put the same code in that module that you'd put in a translator applet, so that code has an independent life on its own and doesn't need to be mixed with the main server code and impair future developments.

On the other hand, translator applets have this advantage that they *enforce* such an isolation.

PS: It is interesting to also see Alfman joining our conversation, although he has less to say to me. And how it actually developed from Kaj-de-Vos' one small vague comment.

Actually, we have already chatted on that topic, and I have taken his feedback into account, so it's normal that he has less things to tell me this time ;)

Alfman has a quality which I'm really fond of, as far as OSdeving discussions are concerned : he likes precision. When he notices a blanket statement, he is going to press its author until he either puts some true arguments on the table or quits. That makes him a precious ally to have when designing things.

Edited 2011-06-01 19:01 UTC

Reply Parent Score: 1

RE[24]: Comment by Kaj-de-Vos
by xiaokj on Wed 1st Jun 2011 23:44 in reply to "RE[23]: Comment by Kaj-de-Vos"
xiaokj Member since:
2005-06-30

I'd argue that nothing prevents system API manufacturers from putting all compatibility kludges in a separate code module, separating them from the rest. After all, you put the same code in that module that you'd put in a translator applet, so that code has an independent life on its own and doesn't need to be mixed with the main server code and impair future developments.

Theoretically possible, but in the real world, it is hard to even envision, let alone actually do it.

On the other hand, translator applets have this advantage that they *enforce* such an isolation.

Well said. I cannot even put it better myself.

...so it's normal that he has less things to tell me this time ;)

You caught my idea wrong. I was finding it funny he didn't talk to me, not you. But of course.

Alfman has a quality which I'm really fond of, as far as OSdeving discussions are concerned : he likes precision. When he notices a blanket statement, he is going to press its author until he either puts some true arguments on the table or quits. That makes him a precious ally to have when designing things.

Certainly. If not for a lack of real exp myself, I would have joined in.

Reply Parent Score: 2