NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/minix/4310

Text File | 1992-08-26 | 3.4 KB | 67 lines

Newsgroups: comp.os.minix
Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!sun1.ruf.uni-freiburg.de!news.belwue.de!news.uni-tuebingen.de!wega!flebbe
From: [e-mail] (Olaf Flebbe)
Subject: Re: Basic MINIX ST questions (long)
Message-ID: <flebbe.714822649@wega>
Sender: [e-mail] (News Operator)
Organization: TAT (Theoretical Astrophysics Tuebingen), U. of Tuebingen, FRG
References: <[e-mail]>
Date: Wed, 26 Aug 1992 09:50:49 GMT
Lines: 55

[e-mail] (Allen Williams (co-op)) writes:


> As the book was for the IBM PC, I have some questions about the Atari
>specific version of Minix. These are basic questions but hopefully not
>something people are tired of hearing:

>      I know there is no paging of memory for Minix, as there isn't
>    any good hardware support. However, is memory accesses outside
>    the process space restricted? Can I write an user program to
>    diddle with the kernel or file system space? If so, is this
>    just one of those things you're not supposed to do but can
>    do anyway? If I access memory outside my program space, will a
>    core dump be generated?
Yes, you can access memory outside your private user space. But you
are not supposed to do it. A bus error (causing an core dump)  will be
generated simular to TOS if you want to read/write on memory below
some magic address. esp. referencing NULL will do an core dump.

>    How are memory holes handled? I'm afraid I'm not clear on this
>    feature. Is memory compacted as the holes become too small or
>    too numerous, or does one have to reboot Minix when no new
>    processes can be created due to none of the holes being big enough?

There is no memory garbage colletion. When a new process come into life,
the kernel checks for the first chunk of memory which fits. One has to
kill processes to if there are big holes left.

>    On the Atari, how is program expansion handled? For the IBM PC
>    in the minix book, there is a system call called "brk" which will
>    allow the program to grow upward toward the program stack. I think
>    this was due to a limitation of the 286's 64k segmentation. I would
>    think that Atari Minix won't have this limitation. Do I use a
>    malloc() call, and the memory manager will allocate any free memory for
>    my process, and not just the memory between my process and the stack?

Each program has a fixed upper limit for its memory. Each executable
has this size written somewhere in the file.
From this fixed amount sbrk (or brk) can get its memory. malloc is a
library function calling brk(). There is a program called chmem which can
increase/decrease the amount of memory which the program can allocate.

[Hardware hacking]
>    Perhaps a small controller could provide some rudimentary memory
>    management, such as keeping track of the pages assigned and making
>    sure that the cpu doesn't stray from the proper areas of memory
>    it's supposed to access. It sounds like a bit of work, and I
>    would like to hear of other people's efforts in this matter.
If you want to design a mmu: Do it. Or change the 68000 to a 68030 and
let the MMU do the work. I don't know whether the TT version of minix
--which still doesn't exists officialy -- do some MMU work on this. Perhaps
Frans Meulenbroeks can tell you something on the MMU.
--
  Olaf Flebbe,  Theoretische Astrophysik Tuebingen
  Internet:     [e-mail]