Path: utzoo!utgpu!watmath!att!pacbell!ames!indri!uakari.primate.wisc.edu!csd4.milw.wisc.edu!bbn!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Minix, Unix on the Amiga, and flames on AmigaDOS braindamage...
Message-ID: <7570@cbmvax.UUCP>
Date: 8 Aug 89 05:43:43 GMT
References: <1610@uw-entropy.ms.washington.edu> <195@VAX1.CC.UAKRON.EDU> <26900@agate.BERKELEY.EDU> <4084@sugar.hackercorp.com>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 101

In article <4084@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>Because unlike you he understands that AmigaDOS is the name of the Tripos
>derived file system. The rest of the system, the Exec, drivers, etc..., are
>together called AmigaOS.

	There's more than just the filesystem.  It includes a load of BCPL
library routines used by the dos calls and bcpl programs (and filesystems).

>> AmigaDOS (among other OSs) got it right, and chose tasks for basic IO
>> objects. If you don't think this is right, I'll write a task that uses
>> a disk and acts like a file. You write a file that acts like a task
>> (using whatever hardware you need).
>
>Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic
>object. AmigaDOS uses a task interface, but the basic object is the lock or
>file handle. Mixing models like this is a bad idea, and the main reason people
>get frustrated with AmigaDOS.

	Actually, the filehandle is not the basic object: the coroutine is
(for OFS/FFS).  The filehandle is a handle on the coroutine in the FS.  The
FS is full of coroutines.  Makes some things very clean, makes others very
tough to add.

>Rubbish. Every AmigaOS program has to have a substantial amount of code
>devoted to resource tracking... a job better assigned to the O/S. If you
>don't want to call that "coding around" the problems, then you're just playing
>games with words.

	Many requests for what people call "resource tracking" are actually
requests for memory protection.  I consider any program on ANY os that doesn't
free what it allocates (memory, file locks, whatever) to be at best poorly
written.

	Not to say some resource tracking wouldn't be a bad idea.  However,
in a multitasking, lightweight process machine you have to be careful: many
programs pass off resources (permanently) to other processes (or to no one:
public structures, for example.)  One can't merely add freeing of resources
on program exit to current programs; they'll break.

>But in UNIX the program doesn't have to *know* what goes on inside the kernel.
>You have to dig around in internal AmigaDOS data structures to do all sorts of
>vitally important things... like getting a list of devices, an operation that
>comes for free with UNIX.

	Hmm, ps seems to know a lot..., and what's the purpose of /dev/kmem,
eh?  :-)

	I agree about the AmigaDOS structures.  Personally I prefer modules
closer to Abstract Data Types (ADT's):  access should be mostly by functions,
all reasonable operations supported, as many data structures as possible
_totally_ hidden.  I particularily abhor applications allocating system
data structures and passing them to the system.

>> Elegant is hardly the word. Of course, if you just want a "here's a
>> pair of fd's" type interface, that's not hard to build on top of
>> PIPE:.
>
>If you want it transparent to the programs being piped, it sure is. The
>only decent implementation of *that* is Bill Hawes' PIP device, which
>uses a non-standard call to get a pair of file handles that really do
>work like UNIX pipes. It's a botch.

	You don't need to do that.  Named pipes can work quite nicely in
place of Unix pipes; most of the work in using pipes is in the shell.  I
know, I've written shells that do unix piping ('|') and pipe-handlers before
(before I came to commodore).  I see no need for Bill's special packets.

>> What about them? The versions in my Amiga library are slightly
>> different than the ones on Unix, but not enough to cause any problems.
>
>Unless you want to port reasonably sophisticated UNIX software, such as
>ASH.

	Suprise!  AmigaDos is not Unix!  It doesn't claim to be.  What's
going on here is most C compilers in most systems try to provide a bunch
of fairly standard Unix functions to make porting Unix programs easier.
Note the word "easier".  Since the OS they run on top of is not Unix,
the library routines often aren't 101% Unix XYZZY compatible.

	This doesn't mean you can't do the things you want to in AmigaDos:
just that you may have to do them a different way (the fork() and exec()
calls were not given to DMR on a stone tablet).

	I also don't mean to say all the functionality that should be is
in the current DOS.  It isn't.  I'm working to correct this; I think you'll
like what you see. :-)

>What part of UNIX? The only part that matters is the program interface.
>What's on the other side varies widely. Compare and contrast Mach (the
>basic object is an address space) or Minix (tasks and message ports) to
>conventional UNIX (co-routines) or Eunice (emulation on top of VMS).

	Spoken like a true portable Unix application writer.  :-)
Seriously, most Uni are still using the ancient 'monolithic monitor' model
for their kernel.  There are some _small_, hesitant steps away from it, but
not very fast, and not mainstream.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"