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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2010-03-08
Member since:2010-06-09
I will, but I got the feeling that you are not ready to accept the criticism you asked for. The overarching problem here is that most of the world is in mental models that consist of code instead of data, and thus code calls instead of semantic interchange, and thus implementation details of how to do something, instead of what to do. It turns out to be hard for people to switch models, so I have stopped trying over time.
Member since:2010-06-09
In RPC, you assume that the remote end has a procedure you can call. That's a big assumption. To make it work, you assume that the remote procedure is written in the same programming language. That's a huge implementation "detail".
Remote objects are just an object oriented extension of the RPC concept. They were en vogue in the nineties, when everybody switched to remote architectures. This was when CORBA and other such methods were found to be too cumbersome.
Messaging has a long history, really. These lessons were already learned in AmigaOS, BeOS, Syllable and new messaging systems such as 0MQ. You can also ask yourself what the most successful remote protocol does. Is HTTP/HTML RPC based?
Member since:2010-03-08
Well, this looks like the beginning of an answer, so if you allow me...
At the core, we have this: daemon process wants to inform the kernel that there's a range of things which it can do for other processes. The procedure/function abstraction sounded like the simplest one around the "things which it can do" concept to me.
Hmmm... Can you mention a modern, serious programming language (joke languages like BF don't count) that does not have the concepts of a function or a pointer ? Because once the concepts are there, dealing with the switch from one language to another during a call is just a matter of gory implementation magic.
I'd prefer it if we didn't put the notions of long story and success in there. DOS has a long story, Windows is successful. Does it mean that these are examples which everyone in the OS development community would like to follow ?
Edited 2011-05-29 20:05 UTC
Member since:2011-01-28
"In RPC, you assume that the remote end has a procedure you can call."
Well, that's a given, but we're talking semantics here. Whether your talking about dos interrupts, linux syscalls, vector calls, we're still technically calling a "procedure".
I guess you are referring to different mechanisms for parameter passing?
It's true there are different incompatible types (for example __cdelc or __stdcall), and these may even have subtle differences from platform to platform (passing floating point values in ST0 instead of stack). But these are strictly binary differences, all models are compatible at a source level - I just need to recompile.
"That's a big assumption. To make it work, you assume that the remote procedure is written in the same programming language."
Why did you ignore my counter example? In any case, this is no different than windows or linux being written around C callers.
"That's a huge implementation 'detail'."
Exactly, it's an implementation detail which end users rarely if ever need to concern themselves with. People don't need to know the calling conventions of their platforms to be able to write code.
So, the Xbox One disaster continues. Microsoft's policy for dealing with the used games market has reportedly leaked - and it's a clear and direct attack to destroy the used games market. Prices for used games will be set at the retail value of a new game, and retailers have to hook into Microsoft's computer systems and comply with Microsoft's terms and conditions.At an event earlier today, Microsoft unveiled the next Xbox - the third model, but confusingly named Xbox One. The big focus was TV, integrated Kinect, and all the other stuff we all expected to be forced down our throats. I think it took them 25 minutes to actually come to what should be the core of the story: gaming. Nothing groundbreaking in the gaming department, except for how Microsoft intends to handle the used games market and borrowing games from friends: pay up, buddy!
The day has finally come! Jolla has finally announced the launch device for its Sailfish operating system - and by god this is a looker. It's decidedly different from other phones out there, but it has good specifications and carries a relatively reasonably price tag - EUR 399, and it's up for pre-order today, shipping in the fourth quarter of this year.
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.
Member since:
2011-01-28
Kaj-de-Vos,
"Leaking of implementation details is detrimental to interfacing with other hardware architectures"
I understand all your initial criticisms, however I'm curious how an RPC interface leads to leaking of implementation details?
Corba interfaces are completely portable across many languages/platforms, including scripting languages.
Heck, just using corba itself would provide instant RPC compatibility with almost all serious languages out there.
If corba is too heavy weight to use in the OS, one could still provide an OS binding for it - that might even be a novel feature for the OS.