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

Text File | 1992-08-25 | 5.3 KB | 109 lines

Newsgroups: comp.os.minix
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!udel!louie!minix
From: [e-mail]
Subject: Re: Basic MINIX ST questions
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET News Service)
Nntp-Posting-Host: louie.udel.edu
Organization: DSDIC
Date: Wed, 26 Aug 1992 07:47:18 GMT
Approved: usenet=[e-mail]
Lines: 95

In article <1992Aug25.185004.13946@vampire> you write:
> I've purchased Andy T.'s Minix textbook, and I found it interesting and
>a sight better more informative than the dull and boring OS book I used
>for an OS class I took. I especially appreciated the extra detail in file
>systems, somtheing that was glossed over in the class.

It's a damn good book, yes. Its biggest failing now is that Minix has moved
on quite a bit from the original version. But it's still fairly valid.

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

Kinda hard to say. I hope you'll get a more authoritive answer on the question
of Minix-ST memory management, because I'd really like to know more about it
myself. But as I understand it, the executable file contains (GEM-DOS)
relocation information, so that the executable can fit anywhere into memory
when it's first exec'ed. fork() is handled by "shadowing", and I've a horrible
suspicion this basically means that each process shares the same tex segment
(which is good), and that they also have to "share" the same data area, which
means that on each context switch, the data areas are swapped as a unit. I'm
not convinced of this (haven't seen the code to do it, for a start), but it's
all I can think of to explain the slow performance of programs that fork but
don't exec, and I don't know of another way of doing fork without making all
memory references relative to the contents of (say) A5.

ANYWAY - you do get core dumps, yes. Mostly for things the ST can trap for:
illegal instruction, bus errors, etc. You also get SEGV signals, which I
presume mean that you're out of the memory range altogether (or are writing
to ROM), because there's nothing in the hardware to stop you overwriting
Minix itself.

Core dumps themselves aren't actually any use, because there isn't anything
you can do with them (at least, not at *my* level of Minix hacking). But
you do get mdb, which is a useful debugger.

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

I don't think there's any compaction of memory, since the relocation of
processes is only done when they're first loaded. You don't have to reboot,
though - you just kill off processes until you're left with enough space to
run what you need.

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

No, the memory allocation system is the same as is described in the book,
with the exception that a fork doesn't need to copy the text segment -
the executable contains the total amount of memory required, and that gets
allocated at the start. All brk() does is increase the top-of-heap pointer
*towards* that limit - the pages are already allocated to the process. There's
nothing to stop your process going beyond the limit, though, which can lead
to some very strange behaviour.

>    I was thinking of building a memory mangler for the ST, based on
>    my understanding of how Minix works. If a process has a lower and
>    upper limit that it can access (if my supposition about malloc()
>    above doesn't hold true), then perhaps when the cpu is in user mode
>    and it tries to access memory outside this range, an interrupt is
>    generated and the kernel kills the process and generates a core
>    dump.

That'd be nice, but personally I'm entirely a software person; someone else
can solder the beasties:-).

> Well, I think that's enough questions to ask for now. I would be deeply
>appreciative to hear from other Atari (or any other computer) Minix
>hackers!

Well, if you get any *decent* answers on how the ST shadowing works (or
indeed any other answers), I'd really like to see them.

Hope this has been of some help, though.

Steve.
--
-----------------------------------------------------------------------------
Steve Kilbane, MDD, CEGELEC PROJECTS Ltd, Boughton Road, Rugby, CV21 1BU,
England. Tel: [phone] x3493. email:[e-mail]
Disclaimer: I don't speak for my employers. I don't speak for me. I mutter.
                       "(the_winds)caution();"
--
Mail System (MMDF)