Linked by Hadrien Grasland on Sat 5th Feb 2011 10:59 UTC
OSNews, Generic OSes So you have taken the test and you think you are ready to get started with OS development? At this point, many OS-deving hobbyists are tempted to go looking for a simple step-by-step tutorial which would guide them into making a binary boot, do some text I/O, and other "simple" stuff. The implicit plan is more or less as follow: any time they'll think about something which in their opinion would be cool to implement, they'll implement it. Gradually, feature after feature, their OS would supposedly build up, slowly getting superior to anything out there. This is, in my opinion, not the best way to get somewhere (if getting somewhere is your goal). In this article, I'll try to explain why, and what you should be doing at this stage instead in my opinion.
Thread beginning with comment 461295
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: Not always rational
by Alfman on Tue 8th Feb 2011 08:16 UTC in reply to "RE[8]: Not always rational"
Alfman
Member since:
2011-01-28

"As I said, it's possible to have some IPC cost and page table manipulation only when a process is started....What's the problem with this approach ?"

This is one possible approach, however it limits the type of IPC which can be used.

In particular, this approach forces us to copy data into and out of the shared memory region. Furthermore, if the shared memory region contains any critical data structures, they could be clobbered by a module pointer bug which could cause other modules to crash.

The segmentation approach would allow the well defined/safe IPC code to access any data explicitly shared through the IPC protocol without any copying.
All other code in the module is isolated since the compiler would not allow it to change the segments.

Therefor, selectors do have different protection semantics than a static page table.

Reply Parent Score: 1

RE[10]: Not always rational
by Neolander on Tue 8th Feb 2011 08:41 in reply to "RE[9]: Not always rational"
Neolander Member since:
2010-03-08

This is one possible approach, however it limits the type of IPC which can be used.

In particular, this approach forces us to copy data into and out of the shared memory region.

Why ? We stay in the same process, just calling code from the shared memory region.

Furthermore, if the shared memory region contains any critical data structures, they could be clobbered by a module pointer bug which could cause other modules to crash.

Indeed, that's why I think global/static variables should be avoided like pest in shared functions. A state in shared code is a disaster waiting to happen.

The segmentation approach would allow the well defined/safe IPC code to access any data explicitly shared through the IPC protocol without any copying. All other code in the module is isolated since the compiler would not allow it to change the segments.

Therefor, selectors do have different protection semantics than a static page table.

Can you describe in more details how it would work for some common IPC operations ? (sending/receiving data, calling a well-defined function of another process...)

Edited 2011-02-08 08:52 UTC

Reply Parent Score: 1

RE[11]: Not always rational
by Alfman on Tue 8th Feb 2011 10:45 in reply to "RE[10]: Not always rational"
Alfman Member since:
2011-01-28

"Why ? We stay in the same process, just calling code from the shared memory region."

I was assuming that you intended to passed all data around through a shared data region. But it sounds like you want to use protected IPC functions to copy data directly between isolated module heaps?

That's not bad, I guess it'd need to be profiled. But that single copy disturbs me, a macrokernel wouldn't need to do it.

"Can you describe in more details how it would work for some common IPC operations ?"

What I had in mind was basically, assuming we had virtual isolation capabilities of a kernel VM, an IPC mechanism could transfer object references between modules. The objects themselves would remain in place, and there'd be no copying.

To do this efficiently+safely the source module could have only one reference to the object being transfered, but this isn't unreasonable. Also, presumably any references within the object being transfered would also be transfered recursively.

I don't have time to discuss it further right now.

Reply Parent Score: 1