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 475450
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[20]: Comment by Kaj-de-Vos
by xiaokj on Wed 1st Jun 2011 14:37 UTC in reply to "RE[19]: Comment by Kaj-de-Vos"
Member since:

Yes, I mean to shift the compatibility kludges to the translator. The idea is that you can make a major version translator and many minor version translators. In this way, the server code can march forward as it likes; once a translator has been created, breakage is next to free of cost. At the end, when major releases are made, all the minor translators can go to nirvana whereas all the old code can just use the major version translators. There will be a V1 -> V2 translator, a V2 -> V3 translator, so on and so forth, and once that is done, there will be no need for any modifications to them. They must, of course, be able to be chained, so that the maintainer does not need to make V1->V3 translators and such nonsense.

In this method, the size of the translator is bounded by how often major releases are made. It actually encourages major releases, not discourage. And given that it is major releases, major breakages are encouraged too.

I intend this to look more like when you upgrade packages on apt -- the system would try its best to seamlessly upgrade the machines' configuration along with the packages. When it gets into trouble, the user can be asked, or some other appropriate measure can be taken on a case-by-case basis. If seamless translation can be done, so be it. If not, the world will not end.

Leaving things to the API doc means manual intervention is required by the original author. I hope to minimise this to a minimum. If you have a machine parse-able transition plan, then the machine can hobble on as it goes, only dying when it really needs to. Sometimes, you don't even have access to the original codebase / author, so this is actually not so far-fetched.

Of course, the final granularity of the implementation is up to the coder to decide, so I hope I did give you some interesting ideas.

Reply Parent Score: 2

Neolander Member since:

That's indeed quite an interesting track to follow. It would make compatibility breakages less of an issue, which could lead to development patterns that are quite different from the ones we know.

Initial development would be faster, because developers would be less afraid to make design mistakes. They'd know that no matter what they do, they can easily fix it through incompatible changes and translation layers later.

It would be less like "do it right the first time" and more like "get it out of the door now, fix it later". It is kind of like the Linux stable ABI debate : should Linux devs take the time to design a good ABI once and for all, and only break it infrequently, or be left free to break it whenever they want and rewrite third-party drivers so that they still work, which allows faster development ?

I still tend to prefer the first approach myself, so I think I won't go this far, but I admit that's totally a very interesting OS design path to follow.

Edited 2011-06-01 15:15 UTC

Reply Parent Score: 1

RE[22]: Comment by Kaj-de-Vos
by xiaokj on Wed 1st Jun 2011 15:52 in reply to "RE[21]: Comment by Kaj-de-Vos"
xiaokj Member since:

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