🚀 go-pugleaf

ulowell!info-minix is the mailing list used by the group working on
the Minix port to the Amiga. Spectators are allowed, and I'm one.
Given the discussion of Minix here, I thought the following would be
of general interest.

Also, since Amiga Exec is related to (is identically?) Tripos Exec,
I'll take this chance to ask if anyone out there is running Tripos
(Stride & similar companies offfer it as an option), and if so to tell
us aobut it.

	<mike

------- Forwarded Message

Date: Sat, 14 Feb 87 00:58:25 est
From: Jeff Kelley <ames!harvard!wanginst!decvax!watmath!watdragon!jvkelley@cad.berkeley.edu>
Message-Id: <8702140558.AA06093@watdragon.uucp>
To: ulowell!amiga-minix
Subject: Some initial comparisons of Amiga's Exec and MINIX


After perusing the first couple of chapters of Tanenbaum's book, I've
got a few comparisons to make between Amiga's Exec and MINIX.

Processes:

	- If you want more than (NR_TASKS+NR_PROCS), you get to change
	  those constants and recompile a portion of the OS and link it.
	  I prefer Exec's flexible approach, with no absolute limit
	  on the number of processes, even though it does mean a *little*
	  overhead in terms of CPU usage and memory.
	  
	- THREE, count them, THREE different priority levels!  (And only
	  one available for user processes.)  What if I've got a CPU
	  intensive job that I want to finish in the next day or two?
	  If I run it in the background, it will split time equally
	  with any short jobs I want done NOW.  Give me Exec's 256
	  priority levels any day.

Message Passing:

	- On the 68000,
	  with its large linear address space, it may be best to use
	  Exec's approach of passing pointers to messages around, rather
	  than copying them.  Does this result in a less secure system?
	  Probably, but I'd like to hear comments about how to make
	  any OS on the Amiga secure.

	- MINIX doesn't have an asynchronous send. (Well, I suppose you
	  could fork() a child and have it do the send, but that's a lot
	  of overhead...)
	  
Memory Management:

	- Is fork() really necessary?  This seems to be the main reason
	  why it is necessary to restrict code and data/stack to be in
	  contiguous 64k regions.  Wouldn't it be better to support
	  vfork(), which would just create a new process from an 
	  executable file, with a few environment variables preset
	  (i.e. stdin, stdout, stderr).

	- If Amiga-MINIX doesn't restrict processes to 64K of code and 64K
	  of data/stack, will it be possible to kill() processes?

I don't want to give the impression that I don't like MINIX, I'm just
trying to bring up a few topics for discussion. (And point out how good
Exec is.)  There's an awful lot I like about MINIX, I'm just not
mentioning it here.

No (sane) Amiga user is going to be willing to give up Intuition.
Just what are the ramifications of trying to integrate this with
Amiga-MINIX?  (Legal and technical)

Comments, questions, answers, *FLAMES* and donations(:-) are welcomed.

	Jeff Kelley
	jvkelley@watdragon.UUCP

UUCP  :	...!{decvax|ihnp4|clyde|allegra|utzoo}!watmath!watdragon!jvkelley   
ARPA  :	jvkelley%watdragon%waterloo.csnet@csnet-relay.arpa 
CSNET :	jvkelley%watdragon@waterloo.csnet

------- End of Forwarded Message