Hello,

I tried Minix 3 yesterday and installed it. I have some questions regarding
my short experience.

- Is it possible to have the text/mode terminal emulator work in a more
natural way without reprogramming tty? For example, I would like the Home
and the End keys to work, and the Delete key to delete de character that
lies under the cursor (and pull the others to the left).

- While running X, is it possible to return to text mode without exiting X?
I mean, in Linux and *BSD we do this just by pressing Ctrl+Alt+Fx, but in
Minix this doesn't seem to work. Or is this caused by bad configuration of
the server? Or both (Minix does not support the mechanism used by X to go
back to text mode while still living)?

- Given that, in part(8), "You can move all over the place with the arrow
keys, change values, and make a mess of your partition table real quick.",
is there any reason for it still being included, instead of some other
partition table editor?

Thanks,
JJ

Jo??o Jer??nimo wrote:
> Hello,

> - Given that, in part(8), "You can move all over the place with the arrow
> keys, change values, and make a mess of your partition table real quick.",
> is there any reason for it still being included, instead of some other
> partition table editor?

Yes there is. It works (if you know what you're doing), and it runs on
Minix. AFAIK no other partition editor has been ported to Minix. However,
if you don't trust Minix part (or yourself), you can always look around
for a Linux live CD with a partition editor bundled into the software,
it's bound to be around somwehere. See
http://www.minix3.org/doc/partitions.html for some pointers on where to
look.

Regards,

Jens


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

J.F. de Smit escreveu:

> Jo??o Jer??nimo wrote:
>> Hello,
>
>> - Given that, in part(8), "You can move all over the place with the
>> arrow
>> keys, change values, and make a mess of your partition table real
>> quick.", is there any reason for it still being included, instead of some
>> other partition table editor?
>
> Yes there is. It works (if you know what you're doing), and it runs on
> Minix.

Yes, I know what I'm doing because I have (some) experience dealing with
partitions.
But it's true that the interface is a bit tricky to work with, and pretty
easy to make a mistake.

> AFAIK no other partition editor has been ported to Minix. However,
> if you don't trust Minix part (or yourself), you can always look around
> for a Linux live CD with a partition editor bundled into the software,
> it's bound to be around somwehere.

Ok, ok. I just wondered why, because an OS like Minix needs to have *some*
degree of self-sufficience for configuring hardware (here, I consider
editing the partition table as "hardware configuration") and installing the
system.

--
João Jerónimo

On Wed, 13 Aug 2008, João Jerónimo wrote:

> Hello,
>
> I tried Minix 3 yesterday and installed it. I have some questions regarding
> my short experience.
>
> - Is it possible to have the text/mode terminal emulator work in a more
> natural way without reprogramming tty? [trim]

> - While running X, is it possible to return to text mode without exiting X?
> I mean, in Linux and *BSD we do this just by pressing Ctrl+Alt+Fx, but in
> Minix this doesn't seem to work. [trim]

I do not have Minix installed, but I have been following this ng out of
somne interest. My understanding is that Minix is not supposed to be
all things to all men. It is not supposed to be Unix or Linux. It is
not supposed to do everything that those operating systems can. It is
supposed to be a simple operating system, reliable and safe. For
example, I work part time for one of the largest retail bookstore
chains in the United States. We use computerized handheld scanners
that use, of all things, a version of DOS (ROM-DOS)!!! I have the
impression that, apart from its educational value, Minix is intended to
be used for safe and reliable applications such as this, not to run the
whole world.

--
Paul Bartlett

Paul Bartlett wrote:

> My understanding is that Minix is not supposed to be
> all things to all men.

No OS is supposed to be that kind of thing, although some get pretty close
to that stage.

> It is not supposed to be Unix or Linux.

Of course not.

> It is not supposed to do everything that those operating systems can.
> It is supposed to be a simple operating system, reliable and safe.

Of course not.

> For example, I work part time for one of the largest retail bookstore
> chains in the United States. We use computerized handheld scanners
> that use, of all things, a version of DOS (ROM-DOS)!!! I have the
> impression that, apart from its educational value, Minix is intended to
> be used for safe and reliable applications such as this, not to run the
> whole world.

Now, what does this have to do with my question?

JJ

Jo??o Jer??nimo wrote:
>> AFAIK no other partition editor has been ported to Minix. However,
>> if you don't trust Minix part (or yourself), you can always look around
>> for a Linux live CD with a partition editor bundled into the software,
>> it's bound to be around somwehere.

> Ok, ok. I just wondered why, because an OS like Minix needs to have *some*
> degree of self-sufficience for configuring hardware (here, I consider
> editing the partition table as "hardware configuration") and installing the
> system.

And so it does. It's not the easiest program to use, true, but it's a
powerful tool. Powerful tools usually have the power to break stuff as
well as fix stuff. And there's just no substitute for the experience of
rewriting the partition table on a running system (as I did once). It's a
very educational experience...

Regards,

Jens

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

On Thu, 14 Aug 2008, João Jerónimo wrote:

> Paul Bartlett wrote:
>
>> My understanding is that Minix is not supposed to be
>> all things to all men.
>
> No OS is supposed to be that kind of thing, although some get pretty close
> to that stage.
>
>> [trim]

>> For example, I work part time for one of the largest retail bookstore
>> chains in the United States. We use computerized handheld scanners
>> that use, of all things, a version of DOS (ROM-DOS)!!! I have the
>> impression that, apart from its educational value, Minix is intended to
>> be used for safe and reliable applications such as this, not to run the
>> whole world.
>
> Now, what does this have to do with my question?

My point is that your question may not be directly answerable within
the original design features of Minix. Perhaps Minix was never
intended to be able to run every graphical user interface (X, Gnome,
KDE, ICE, whatever) under the sun, because its design doals were
simple, perhaps including only a simple text user interface.

--
Paul Bartlett

J.F. de Smit escreveu:

> And so it does. It's not the easiest program to use, true, but it's a
> powerful tool. Powerful tools usually have the power to break stuff as
> well as fix stuff. And there's just no substitute for the experience of
> rewriting the partition table on a running system (as I did once). It's a
> very educational experience...

Yes, I know (in fact, it's not much less powerful than most
partition-editors).
But it's interface is also a bit confusing at first (even to people who are
used to work with disk partitions).

Please, my original intent was not to get a flame war for free. I was only
asking if there was any special reason or it was just because it works, and
no one has to date bothered writing another one. :-)

--
João Jerónimo

Paul Bartlett escreveu:

>>> For example, I work part time for one of the largest retail bookstore
>>> chains in the United States. We use computerized handheld scanners
>>> that use, of all things, a version of DOS (ROM-DOS)!!! I have the
>>> impression that, apart from its educational value, Minix is intended to
>>> be used for safe and reliable applications such as this, not to run the
>>> whole world.
>>
>> Now, what does this have to do with my question?
>
> My point is that your question may not be directly answerable within
> the original design features of Minix. Perhaps Minix was never
> intended to be able to run every graphical user interface (X, Gnome,
> KDE, ICE, whatever) under the sun, because its design doals were
> simple, perhaps including only a simple text user interface.

Of course not. Originally, Minix was mainly target at operating system
classes in univercities.
However, now it /even/ runs X windows, isn't this wonderful?
Afaik, paging is currently being implemented, even though it may be
considered unnecessary for the initial Minix's goals.

Apart from that, I was *only* asking a question. I *do* respect AST's goals,
and understand that Minix isn't intended to have, at least in it's "main"
development branch, all the fancy features of a full-blown operating
system.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

Paul Bartlett escreveu:

> (X, Gnome, KDE, ICE, whatever)

Another note: I'm not interested in runing KDE nor Gnome (well, I would if
it was supported, but that's not the point here).

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

Jo??o Jer??nimo wrote:
> Of course not. Originally, Minix was mainly target at operating system
> classes in univercities.
> However, now it /even/ runs X windows, isn't this wonderful?
> Afaik, paging is currently being implemented, even though it may be
> considered unnecessary for the initial Minix's goals.

Perhaps not, but it would make stuff a lot easier to use (especially X,
allocating each component the memory it needs can be a real pain).

> Apart from that, I was *only* asking a question. I *do* respect AST's goals,
> and understand that Minix isn't intended to have, at least in it's "main"
> development branch, all the fancy features of a full-blown operating
> system.

Well, questions tend to invite answers Don't worry, we're nice people,
we simply get to the point a bit fast sometimes, without the nice
introductions.

The thing is, Minix is really growing at the moment, as well as settling
into its new, third version design. With this growth come some growth
problems, which may lead to unexpected situations. There's some great
software out there (like Apache, PHP, libxslt), but getting X to work can
be a real pain. Not everything is as polished as you might expect it.

Oh, and the most likely answer to any "why is Minix lacking tool/feature here>" question is: nobody has implemented it yet. So, if you
would like a fancy partition editor, a packet snifffer, a code cleaner,
more file system support, you name it: port it and you'll make all of us
happy.

Kind regards,

Jens


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

J.F. de Smit wrote:
> João Jerónimo wrote:
>> Of course not. Originally, Minix was mainly target at operating system
>> classes in univercities.
>> However, now it /even/ runs X windows, isn't this wonderful?
>> Afaik, paging is currently being implemented, even though it may be
>> considered unnecessary for the initial Minix's goals.
>
> Perhaps not, but it would make stuff a lot easier to use (especially X,
> allocating each component the memory it needs can be a real pain).

Yes. As I have read, Minix puts both the code and data segments in the same
chunck of memory. This real makes stuff very "static", because the stack
grows downwards, which means you couldn't just expand (and move arround if
necessary) the segment when the application demands more heap than was
initially expected (also, due to the sbrk system call spec, you can't just
split the data segment in two parts allocating the rest beyond the
stack)...
Spliting the stack from the heap is also a non-solution, because C compilers
are typically designed to expect a "flat" address space, at least from the
point of view of the application (i.e. the app only sees one segment). In
particular, they expect to be able to access the stack with registers that
are not ESP/EBP, so if DS refered to a different chunk of memory than SS,
segment overrides would have to be used, and additionally the compiler
would have to decide where to use them and where not to use.

Overall, it's better to use paging. After all, 64-bit Long Mode (like a
bunch of alternative architectures) just doesn't support segmentation.

> Well, questions tend to invite answers Don't worry, we're nice people,
> we simply get to the point a bit fast sometimes, without the nice
> introductions.

No problem. I'm used to it. :-)

> The thing is, Minix is really growing at the moment, as well as settling
> into its new, third version design. With this growth come some growth
> problems, which may lead to unexpected situations. There's some great
> software out there (like Apache, PHP, libxslt), but getting X to work can
> be a real pain. Not everything is as polished as you might expect it.

Ok. I understand that OS development is composed of different stages, and
stuff take time to get working right.

> Oh, and the most likely answer to any "why is Minix lacking > tool/feature here>" question is: nobody has implemented it yet. So, if you
> would like a fancy partition editor, a packet snifffer, a code cleaner,
> more file system support, you name it: port it and you'll make all of us
> happy.

Thanks. That's what I wanted to read. :-)
Unfortunatily, I'm very very unstable. And my interest usually vanishes in
one week or two.
But if I come with something useful that runs on Minix, now I know I will be
welcome.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" ' by JJ

Jo??o Jer??nimo wrote:
> J.F. de Smit wrote:
>> Perhaps not, but it would make stuff a lot easier to use (especially X,
>> allocating each component the memory it needs can be a real pain).

> Yes. As I have read, Minix puts both the code and data segments in the same
> chunck of memory. This real makes stuff very "static", because the stack
> grows downwards, which means you couldn't just expand (and move arround if
> necessary) the segment when the application demands more heap than was
> initially expected (also, due to the sbrk system call spec, you can't just
> split the data segment in two parts allocating the rest beyond the
> stack)...

Your first statement isn't exactly correct and also doesn't seem related
to what you say next, but you got the majority of it right. Minix actually
_splits_ the code and data segments by default and assigns them different
segments. This has several consequences:

- address 0 (generally reserved for the NULL pointer) is actually a valid
address in the data segment, because the data segment contains only data
and no text. In situations where code and data share the same segment,
address 0 always contains code and should never be accessed (not even by
icky-icky self-modifying code). However, it is common sense to still
regard 0 as an invalid memory address because you need _something_ to
signal it and it costs you only 1 byte of usable memory

- remote code execution through stack overflow is a lot harder (if not
impossible) to accomplish, because the kernel forbids writing to a code
segment, and the CPU only fetches opcode from the code segment (and not
the data segment). Putting code on the stack and then overwriting a
return address will get you erratic behaviour at best, but more likely a
segfault (because the data+stack segment is much larger than the code
segment and stack addresses are at the top of said segment, so a stack
address as PC is probably invalid).

- 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.

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) and there is no way to give an application more memory
than it was assigned at process creation time. This last thing especially
causes the common "Not enough core" error message when running programs
that (sometimes) require lots of memory.

Regards,

Jens

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

J.F. de Smit wrote:
> João Jerónimo wrote:
>> Yes. As I have read, Minix puts both the code and data segments in the
>> same chunck of memory. This real makes stuff very "static", because the
>> stack grows downwards, which means you couldn't just expand (and move
>> arround if necessary) the segment when the application demands more heap
>> than was initially expected (also, due to the sbrk system call spec, you
>> can't just split the data segment in two parts allocating the rest beyond
>> the stack)...
>
> Your first statement isn't exactly correct and also doesn't seem related
> to what you say next, but you got the majority of it right. Minix actually
> _splits_ the code and data segments by default and assigns them different
> segments.

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.

> - remote code execution through stack overflow is a lot harder (if not
> impossible) to accomplish, because the kernel forbids writing to a code
> segment, and the CPU only fetches opcode from the code segment (and not
> the data segment). Putting code on the stack and then overwriting a
> return address will get you erratic behaviour at best, but more likely a
> segfault (because the data+stack segment is much larger than the code
> segment and stack addresses are at the top of said segment, so a stack
> address as PC is probably invalid).

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.

> - 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.

> 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.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" ' by JJ

In article 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@few.vu.nl | http://www.few.vu.nl/~jfdsmit
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean

J.F. de Smit escreveu:
> 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.

I thought people did not consider segmentation to be performed by the MMU.
Paging is, but segmentation is not.

> 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.

IMHO paging support is much easy to understand than segmentation support (at
least the allocation part).
Segmentation requires allocating a chunk of contiguous bytes in a best-fit
or a first-fit fashion, while paging only requires some sort of page frame
allocator using a stack or a bitmap (but there's no "first-fit"
nor "best-fit" trick in it).

Of course you still need to allocate chunks of contiguous memory, but only
at a higher level; in user mode and at kernel level if you need dynamic
memory allocation in kernel (I heard from Tanennbaum himself that Minix
does not use dynamic memory in kernel land (because it uses one static
buffer per process to support IPC, and suspends the sending process when
the receiving buffer is full), but I may have misunderstood).

>>> - 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.
>
> (...)
> immutable. You won't need copy-on-write techniques, because it's
> prohibited by the kernel and MMU to write to the .text segment.

Sorry. I read "data segment".
Yes, the code segment can be shared. Now I understand this wouldn't be
possible without spliting the code and data segments.

>>> 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.

No if you catched the "overflow" using the Stack Fault.
A Stack Fault to be handled in Ring 0 causes a stack switch (unless the
processor is already in ring 0, but that's not the case), so it's safe.
The kernel could then expand the stack segment or kill the process if it
would run into the heap. This could be done because the library has to call
the kernel (sbrk) every time it expands the heap, so the stack fault
handler could know if there was any space 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.

An expand-down stack segment could avoid this particular problem.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

J.F. de Smit escreveu:

>>> - 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.

Something now came to my mind.
Suppose I'm a (small, in terms of .text) process. I have a high chmem. So
high that I don't fit twice in memory. However, I fit once.
Now, I want to execute another program, that fits in the remaining free
memory. To do this, I need to do fork()+execve(). Does the kernel tries to
clone my data segment after the fork(), thus disabling me from executing
another (small) program?

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

> Something now came to my mind.
> Suppose I'm a (small, in terms of .text) process. I have a high
> chmem. So high that I don't fit twice in memory. However, I fit once.
> Now, I want to execute another program, that fits in the remaining
> free memory. To do this, I need to do fork()+execve(). Does the
> kernel tries to clone my data segment after the fork(), thus
> disabling me from executing another (small) program?

Correct. Fixing this indeed requires copy-on-write which in turn
requires paging, which will probably take substantial time to make it
to a release.

--
With kind regards,
Erik van der Kouwe

Jo??o Jer??nimo wrote:
> J.F. de Smit escreveu:
>> 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.

> I thought people did not consider segmentation to be performed by the MMU.
> Paging is, but segmentation is not.

You're right, I was confusing the MMU and the CPU's segment registers for
a moment there. What I meant to say is that without separate I&D, each
MINIX process has exactly one segment assigned to it, with the only
function of segmentation in this case being memory protection and
virtual-to-physical address translation.

>> 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.

> IMHO paging support is much easy to understand than segmentation support (at
> least the allocation part).
> Segmentation requires allocating a chunk of contiguous bytes in a best-fit
> or a first-fit fashion, while paging only requires some sort of page frame
> allocator using a stack or a bitmap (but there's no "first-fit"
> nor "best-fit" trick in it).

I don't know about that. I think you can only really appreciate some of
the benefits of paging once you understand the fragmentation problem
caused by only using segmentation. I also feel that the implementation of
paging, with the GDT, LDTs, automatic switches and whatnot is a bit more
complex than segmentation.

> Of course you still need to allocate chunks of contiguous memory, but only
> at a higher level; in user mode and at kernel level if you need dynamic
> memory allocation in kernel (I heard from Tanennbaum himself that Minix
> does not use dynamic memory in kernel land (because it uses one static
> buffer per process to support IPC, and suspends the sending process when
> the receiving buffer is full), but I may have misunderstood).

You're correct, the kernel is designed to not need dynamic memory
allocation. I believe there _is_ a malloc() function in kernel space, but
the goal is to never use it. In most IPC calls, the sending process is
blocked until the receiving process has sent a reply back, i.e. fully
synchronous operation. This means that the sending process is only resumed
after the receiving process has called receive(), done something and then
calls send() to return a reply.

> No if you catched the "overflow" using the Stack Fault.
> A Stack Fault to be handled in Ring 0 causes a stack switch (unless the
> processor is already in ring 0, but that's not the case), so it's safe.
> The kernel could then expand the stack segment or kill the process if it
> would run into the heap. This could be done because the library has to call
> the kernel (sbrk) every time it expands the heap, so the stack fault
> handler could know if there was any space left.

This sounds like a workable solution.

>> 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.

> An expand-down stack segment could avoid this particular problem.

True, but it does require a bunch more administration, possibly adjusting
the stack's descriptor on an sbrk call when a process wants to grow the
heap into the space reserved for the stack. But, it moght be worth the
trouble.

Regards,

Jens

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

"Erik van der Kouwe" few.vu.nl> escreveu:
>> Something now came to my mind.
>> Suppose I'm a (small, in terms of .text) process. I have a high
>> chmem. So high that I don't fit twice in memory. However, I fit once.
>> Now, I want to execute another program, that fits in the remaining
>> free memory. To do this, I need to do fork()+execve(). Does the
>> kernel tries to clone my data segment after the fork(), thus
>> disabling me from executing another (small) program?
>
> Correct. Fixing this indeed requires copy-on-write which in turn
> requires paging, which will probably take substantial time to make it
> to a release.

One could still implement copy-on-write using segmentation.
Only, instead of duplicating the pages as they are written, the data segment
needed to be duplicated all at once.
The only problem would be if the parent process wrote something in the
memory immediately after the fork().
(now, thinking about that, it's pretty likely that the parent does that)

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.