Re: Questions about Minix

In article <g8d6ak$6l9$1@xxxxxxxxxxxxxxx> you wrote:
J.F. de Smit wrote:
Joo Jernimo wrote:
I think I got to that conclusion that .text shared the same memory chunk
as .(ro)data somewhat intuitively.
But then I should have released that Minix would discard the majority of the
benefits of using segmentation if it used that scheme.

I believe the original reason to use segmentation was simply to benefit
from the MMU to protect processes from messing up eachother's memory
areas, and nothing more. the "separate I&D" functionality is a new feature
of Minix 3 if I'm correct.

Ok. That's one of the benefits of segmentation, after all.
OTOH, paging-based operating systems are now discovering the NX bit, that
promises to accomplish the same goal. If they granted an user-mode code
segment to processes from the beginning, and a data segment that did not
start at 0, the same goal could be accomplished.

Correct, but this requires paging support from the kernel (not available
yet) and more fine-grained (and thus more complex) memory management (at
the page level instead of at the segment level). I'm not saying it's a bad
idea (it sounds like a good one actually), I'm just trying to figure out
why Minix doesn't support it (yet). Going out on a limb for a bit, it
might even be possible to support both models by tinkering a bit with the
kernel and writing a second, more complex process manager. That way, the
demanding people can have a paged, NX-supporting, fancy-featured system
while students and starting hobbyists can have a working system simple
enough for them to tinker with.

- multiple instances of the same program can share a code segment. This
saves memory, memory transfers and counters fragmentation issues possibly
caused by using large amounts of small segments.

This needs copy-on-write techniques. Unless this "instances" are threads of
the same process.

Sorry about the confusion, but I distinguish a "program" (a description on
disk) from a "process" (an instance of said program, being executed). What
I meant is that several processes running the same program (e.g. 4 bash
shells) can share the same .text segment, as it is guaranteed to be
immutable. You won't need copy-on-write techniques, because it's
prohibited by the kernel and MMU to write to the .text segment.

On the other hand, what you said about the stack and data areas is true:
they share the same segment, and it is fixed. There is no way to prevent a
stack from growing into the heap (only a possibility of detecting it while
context switching)

An expand-down segment descriptor could be used to control stack growth.

True, but this would limit your stack size to some predetermined value,
meaning things go haywire as soon as you run out of stack space, even if
you still have plenty of heap left. By combining heap and stack into one
segment, things will run smoothly until the stack runs into the uppermost
allocated part of the heap. OTOH, the current approach has a race
condition: if the stack runs into the heap, but shrinks back to a legal
size before the kernel gets called due to a trap or interrupt, it is
impossible to tell that the process has destroyed its own heap, leading to
incorrect behaviour.

All in all, I think it is safe to say that we're all _eagerly_ awaiting
the new memory model :)

Regards,

Jens

--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
jfdsmit@xxxxxxxxx | http://www.few.vu.nl/~jfdsmit
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean
.

Relevant Pages

  • Re: "Physical" memory bounds
    ... This gets tedious with discontiguous memory but I don't see ... is placed in the System Heap. ... Out of this, each task's stack is ... The dynamic memory allocator base allocator will use this label as the ...
    (comp.arch.embedded)
  • Re: IAR compiler & MSP430 problem
    ... the linker isn't telling you when you have run our of RAM. ... which produced a prediction of stack use ... chips have different memory resources. ... // segment address range usage ...
    (comp.arch.embedded)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)
  • Re: Questions about Minix
    ... Of course you still need to allocate chunks of contiguous memory, ... in user mode and at kernel level if you need dynamic ... I read "data segment". ... a stack from growing into the heap (only a possibility of detecting it ...
    (comp.os.minix)