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 475450
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