larson@cg-d.UUCP (Steve Larson X5663) (01/14/87)
Well, I just thought that I would put my two cents in concerning the discussion about MINIX on the ST (w/o MMU). I see two alternatives as follows: 1) The compiler produces position independent code which would allow a process to be loaded into memory at any address. However, then you have the problem of fork()ing because the program generates physical non-relocatable addresses (pointers to local data structures, function return address, etc.). 2) The compiler produces position dependent code based at say location 0x100 (somewhat like CP/M). This would then imply that a lot of process "moving" would take place, but also then fork would work. Its possible that overall system performance would be better in case 2 above and that process "moving" may not be so bad with hardware support (blitter?). But, then the discussion would be non-interesting. So, my argument will be that case 1 above is better and the design should be modeled after it. There are different flavors of case 1: - dynamic resolution of global addresses at load time addresses such as function addresses and external (global and static) data structures would get relocated based on the load addresses of the process. - using indirect addressing given some base address at load time same addresses as above but the compiler/loader uses indirect addressing from a register loaded with the base address of the process. Possibly, both of the above flavors could be used, leaving the choice in the hands of the programmer. Flavor 1 would run faster but would require more startup time and would eliminate the ability to strip(1) the file (must have those relocation entries). Flavor 2 would startup faster but its overall performance would be less (except, for some very small programs). The problem that has gained so much attention is what to do about those non-relocatable addresses on the stack when the program does a fork(). These are addresses such as function return addresses (from jsr) or automatic (local) variables which contain pointers to other automatic variables or even global data. These cannot be changed on the fly since no information is available about them. First, some background information about how I imagine the system working. When the first process is loaded (init) space for its text,data and bss is allocated. The stack will also be allocated somewhere preferably directly above the bss and stack growing is not allowed (open for debate). When a program does an sbrk(2) the new space is allocated from the free memory pool and no requirement that is be tacked on to the bss is made. Haven't thought much about brk(2) but it should be ok(?). This would mean that once a process is running its address slot is reserved and never needs to grow. Now, my idea for getting fork(2) to work is as follows: When a process fork()s a flag is set in the proc[] table saying that the parent and child share the same address slot. When either runs it must first acquire the address slot (which will always be the same size for both processes). When a process exec()s then flag can be cleared and the new process built at a non-position dependent location. The only process "moving" is done between the time of a fork() and an exec(), which is probably the vast majority of situations (i.e. a program fork()ing to produce an image of itself is rarer than a program fork()ing to setup for an exec()). The situation where a process fork()s a child then exit()s would be handled similarly as that of an exec(). There are no longer two processes fighting for a specific address slot and the process "moving" doesn't happen (except initially). I might even suggest a new system call that performs a fork() and an exec() (I think I've heard of it named a spoon()). This would eliminate the messiness between fork() and exec() calls. But, I haven't worked out the details out its usage (i.e. what about file redirection or signal disposition). The details of fork() are a little less clear. Maybe the parent should get "moved" out of its slot and let the child run first hoping it will do an exec(). Then when the parent is scheduled it gets "moved" back to its original slot and the "moving" is complete. A fork() and exec() with only two "moves". Example scenario: +------------------+ When the system is booted the memory image is | Slot 0 : init(1) | like the picture at the left. I know there +------------------+ probably will be some other processes but lets | Slot 1 : csh(1) | keep it simple for now. +------------------+ | Slot 2 : | The csh(1) is going to fork() and exec() the +------------------+ date(1) program. | Slot 3 : | +------------------+ 1) process 1 is marked as needing slot 1 and is | Slot 4 : | "moved" to some free memory. +------------------+ | Slot 5 : | 2) the child runs in slot 1 and calls exec() +------------------+ | | 3) exec() creates new process in slot 2. | free mem maybe | | more slots, etc. | 4) date(1) runs from slot 2, prints date and exits +------------------+ | MINIX | 5) csh(1) is scheduled, gets "moved" to slot 1 +------------------+ and continues executing. I realize that the scheduling may not be exactly as above, but it should still work. There must also be some mechanism for maintaining a reference count on slots so one isn't allocated when a process is "moved" out. The shell should be converted to use the spoon(2) system call since it does such a large number of these fork()-exec() combos. In fact, most programs that do this combo should use spoon(2), but the above is necessary for compatibility and the need for fork()s to create multiple images. I think that the problems I mentioned above with spoon()ing could be resolved so this would work. Well, there you have it. Any comments? Anybody interested in doing this Unix(MINIX) on an Atari ST? Just think of all of these interesting problems we will run into. Maybe someone could manage a group of people to do this port. Any volunteers? I also don't see why making a deal with Prentice Hall (it think it was them) do have them distribute MINIX-ST is absolutely necessary. They said we could distribute it to some of our "friends". I would like to see some response from this, I have been seriously considering doing a port like this but have not had much of a base to start from, at least not one that I could legally distribute after it was complete. Steve Larson ...!decvax!cg-d!larson
hays@apollo.uucp (John Hays) (01/19/87)
There is a very good reason that Prentice-Hall should distribute the Atari-ST
version of MINIX (if and when it gets ported):
Andy Tannenbaum deserves a couple of bucks for every copy!
Andy put in a lot of work and should get some renumeration for it -- He has
made the code very accessible (a few copies for friends!!!) and should get
paid for every 'N' copies.
John Hays
[Justa' my opinions]
...!uw-beaver!apollo!hays
...!decvax!wanginst!apollo!hays
GEnie: KD7UW
CIS: 72725,424larson@cg-d.UUCP (Steve Larson X5663) (01/20/87)
> cg-d!decvax!ucbvax!ucbcad!ames!rutgers!mit-eddie!apollo!hays > > There is a very good reason that Prentice-Hall should distribute the Atari-ST > version of MINIX (if and when it gets ported): > > Andy Tannenbaum deserves a couple of bucks for every copy! > > Andy put in a lot of work and should get some renumeration for it -- He has > made the code very accessible (a few copies for friends!!!) and should get > paid for every 'N' copies. I did not mean to imply that I didn't think Andy deserves compensation for his efforts. What I was trying to say was that IF Prentice-Hall would NOT distribute other ports of MINIX it could be done anyway. I also saw an article from Andy stating that work was under way on the Atari ST port. Who is doing it and how do I get in touch with them? Steve Larson ...!decvax!cg-d!larson
pc@eagle.UUCP (05/05/87)
Any news of this, anyone?
billw@wolf.UUCP (Bill Wisner) (05/10/87)
In article <2907@eagle.ukc.ac.uk>, pc@eagle.ukc.ac.uk (R.P.A.Collinson) writes: > Any news of this, anyone? [Don't panic! There is SUPPOSED to be a file from my Mail directory here!] From sdcsvax!seismo!mcvax!cs.vu.nl!ast Wed May 6 08:04:36 1987 Received: by sdcsvax.UCSD.EDU (5.57/5.0) id AA22665 for billw; Wed, 6 May 87 04:00:58 PST Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA06935; Wed, 6 May 87 08:00:29 EDT Received: by mcvax.cwi.nl; Wed, 6 May 87 13:55:10 +0200 (MET) To: wolf!billw From: Andy Tanenbaum <sdcsvax!seismo!mcvax!cs.vu.nl!ast> Subject: Re: MINIX for the Atari ST Newsgroups: comp.os.minix In-Reply-To: <325@wolf.UUCP> Organization: VU Informatica, Amsterdam Date: Wed, 6 May 87 13:41:57 MDT Sender: sdcsvax!seismo!mcvax!cs.vu.nl!ast Message-Id: <8705061342.aa28690@botter.cs.vu.nl> An Atari version is in the works. It is about 2/3 done. It will be announced in comp.os.minix when it is done, later this year. Andy Tanenbaum -- Bill Wisner ..{sdcsvax,ihnp4}!jack!wolf!billw