Linked by Hadrien Grasland on Sun 29th May 2011 09:42 UTC
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 474957
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by Kaj-de-Vos
by Neolander on Sun 29th May 2011 20:02
in reply to "RE[2]: Comment by Kaj-de-Vos"
Member since:2010-03-08
Well, this looks like the beginning of an answer, so if you allow me...
In RPC, you assume that the remote end has a procedure you can call. That's a big assumption.
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.
To make it work, you assume that the remote procedure is written in the same programming language. That's a huge implementation "detail".
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.
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?
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
RE[4]: Comment by Kaj-de-Vos
by Kaj-de-Vos on Sun 29th May 2011 20:21
in reply to "RE[3]: Comment by Kaj-de-Vos"
Member since:2010-06-09
You keep defending your existing notions, instead of entertaining the notion I introduced that is apparently new to you. Do you agree that declarative data is at a higher abstraction level than a procedure call? Do you agree that not specifying an implementation language is simpler than specifying a specific language?
If you are not willing to look at common implementations, lessons from history become meaningless, either good or bad. Do you have experience with messaging in Amiga, BeOS, Syllable, microkernels, REBOL, enterprise messaging, or anything else?
RE[3]: Comment by Kaj-de-Vos
by Alfman on Sun 29th May 2011 20:20
in reply to "RE[2]: Comment by Kaj-de-Vos"
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.
RE[4]: Comment by Kaj-de-Vos
by Kaj-de-Vos on Sun 29th May 2011 20:30
in reply to "RE[3]: Comment by Kaj-de-Vos"
Member since:2010-06-09
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
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.
Linked by David Adams on 05/16/13 4:23 UTC
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."
Linked by Thom Holwerda on 05/11/13 21:41 UTC
"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.
Linked by Thom Holwerda on 05/08/13 14:22 UTC
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.
Linked by Thom Holwerda on 05/02/13 15:28 UTC
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.
Linked by Thom Holwerda on 04/29/13 21:06 UTC
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.
Linked by Thom Holwerda on 04/24/13 22:24 UTC
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.
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Nokia has posted its quarterly results for the first quarter of 2013, and just like the quarters that came before, there's not a whole lot of good news in there. The rise in Lumia sales still can't even dream of making up for the sales drop in Symbian phones, and when broken down in versions, the sales figures for Windows Phone 8 Lumias in particular are very disappointing. In North America, Nokia is getting slaughtered.
Linked by Thom Holwerda on 04/16/13 9:29 UTC
The day has finally come: Google has started shipping Google Glass to the lucky few early adopters. Now that it's shipping, Google has also unveiled a lot more about the API and the specifications of the device itself. While the company had already given out substantial details at earlier occasions, there are still a few surprises here.
Linked by Thom Holwerda on 04/15/13 22:44 UTC
Almost exactly three years ago, I wrote about why OSNews was no longer OSNews: the alternative operating system scene had died, and OSNews, too, had to go with the times and move towards reporting on a new wave of operating systems - mobile, and all the repercussions that the explosion of smartphones and tablets have caused. Still, I was wondering something today: why aren't we seeing alternative operating systems on mobile?More Features »
Sponsored Links
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?