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 461293
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Not always rational
by Neolander on Tue 8th Feb 2011 07:44 UTC in reply to "RE[7]: Not always rational"
Neolander
Member since:
2010-03-08

Now that I have a better keyboard at hand...

In principal, paging can accomplish everything selectors did. In practice though switching selectors is much faster than adjusting page tables. A compiler could trivially ensure that the kernel module didn't overwrite data from other modules by simply enforcing the selectors except in well defined IPC calls - thus simultaneously achieving good isolation and IPC performance. Using page tables for isolation would imply that well defined IPC calls could not communicate directly with other modules without an intermediary helper or mucking with page tables on each call.

As I said, it's possible to have some IPC cost and page table manipulation only when a process is started, and maybe at first function call. Here's how :
-Functions of a process which may be called through IPC must be specified in advance, so there's no harm tweaking the binary so that all these functions and their data end up being in separate pages of RAM, in order to ease sharing. I think it should also be done with segmentation anyway.
-The first time a process makes an IPC call, part of or all of these pages are mapped in his address space, similar to the way shared libraries work.
-Further IPC calls are directly made in the mapped pages, without needing a kernel call or a context switch.

If we are concerned about the first call overhead (even though I'd think it should be a matter of milliseconds), we can also make sure that the mapping work is done when the second process is started. To do that, we ensure that our "shared library" mapping process happens when the process is started, and not on demand.

What's the problem with this approach ?

Edited 2011-02-08 07:45 UTC

Reply Parent Score: 1

RE[9]: Not always rational
by Alfman on Tue 8th Feb 2011 08:16 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