jholbach@wright.UUCP (09/08/87)
I just finished reading Tanenbaum's article about Minix in the Mar/Apr 87 issue of ;login (USENIX Assn. Newsletter). Could someone tell me whether Minix has been ported to the Atari 1040 ST yet and if so, where can it be acquired? Thank you. Jim Holbach Wright State University Dayton, Ohio csnet: jholbach@wright.edu other: ...!cbosgd!jholbach jholbach@wright.UUCP Disclaimer: I'm sure practically everything above is a trademark of somebody or other....
gert@prls.UUCP (Gert Slavenburg) (09/09/87)
A beta release version of Minix for the Atari-ST is currently available and being tested by a (I guess selected) group of people. As far as I understand the real release should be quite soon. Now if we can get the manpower organized to put X-windows V11 on top of Minix we will have a multi process, Unix compatible, windowing O.S. the source of which is fully available ! Proposal to that effect follows. That situation is definitely preferable over GEM, the source of which seems to be unavailable even to Atari itself ! (I have no other explana- tion for Atari not coming out with an improved GEM). Gert Slavenburg
davidh@ucbcad.berkeley.edu (David S. Harrison) (09/09/87)
In article <6080@prls.UUCP> gert@prls.UUCP (Gert Slavenburg) writes: >Now if we can get the manpower organized to put X-windows V11 on top of >Minix we will have a multi process, Unix compatible, windowing O.S. the >source of which is fully available ! Proposal to that effect follows. I am afraid such a proposal is not practical. The size of the executable server for X version 10 (on a VAX) is 110k and normally consumes about 2MB of virtual space when running. A version 11 server is bound to be larger. Unless you are proposing a small subset, I am not sure we will ever see X on a machine with 64k processes (or 128k split I&D). David Harrison (davidh@ic.Berkeley.EDU) (...!ucbvax!ucbcad!davidh)
jum@focus.UUCP (Jens Uwe Mager) (09/12/87)
I have seen the fork code in minix for intel processors, so I am wondering how can fork work on a linear addressed processor without a memory managing unit? Can anyone enlighten me on this theme? -- Jens-Uwe Mager jum@focus.UUCP
apratt@atari.UUCP (09/17/87)
I know how the fork code for the ST's 68000 works in principle, but the guys who are doing the port seem reluctant to enlighten anybody, so here goes: When you fork(), a copy of your data space is stored away in RAM. The parent continues executing, in the hopes that it will do a wait() right away. The child at this point is "ready but swapped out." When the time comes to run the child, it gets swapped in -- the data space of the parent and child are swapped. This goes on until the parent wait()s for the child, in which case the parent stays swapped out until the child terminates, or until the child does an exec(), in which case it stops using the same address space as the parent. Remember that the "swapping" going on is in RAM, not to disk or anything. This is pretty rough -- I haven't looked at the details. The basic idea of shadowing two processes which run at the same address is right, though. Of course, if neither process does a wait or exec, as is the case with tip(1), you end up doing a lot of swapping. I don't know what the performance ramifications are. At least they share text (I think). /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/