Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!umich!gumby!wuarchive!uunet!netxcom!logan
From: logan@netxcom.netx.com (Jim Logan)
Newsgroups: comp.unix.amiga
Subject: Re: Standards for /dev/amiga and Co.
Message-ID: <417@netxcom.netx.com>
Date: 24 May 91 17:50:55 GMT
References: <1991May20.050025.29148@digibd.com>
Distribution: na
Organization: NetExpress Inc., Vienna, VA, USA
Lines: 66

In article <1991May20.050025.29148@digibd.com> rhealey@digibd.com (Rob Healey)
writes:
# 
# 	Some thoughts:
# 
# 	1) Sound, speech and video "servers" would sit in user, kernel
# 	   or a mix of both modes and listen on IPC ports for requests
# 	   to do something. They would prevent processes from stomping
# 	   on each other when it comes to /dev/amiga access. If a user
# 	   didn't need to use /dev/amiga toys then they wouldn't
# 	   start up the servers and take the performance hit caused by
# 	   the servers real time nature. Maybe the real time/configurable
# 	   scheduler in Amiga UNIX could be used here too?

Actually, that was my next project after porting g++.  I wanted to
make some noise on my Amiga, and since Commodore won't let me
install a device driver of my own making, I was going to make a
daemon.  I was kindof thinking of taking NeXT's approach to
device drivers.

# 	2) A library would provide the way to access /dev/amiga features,
# 	   a program wouldn't be aware that the lib was mmap'ing
# 	   /dev/amiga and doing the necessary bookkeeping. From the
# 	   program point of view this would all look like neat little
# 	   function calls.

Agreed.

# 	3) It would probably be best to implement all this on top of
# 	   /dev/amiga so that no more kernel or system hooks are
# 	   needed. Maybe a "super server" could do the mmap call
# 	   on /dev/amiga and then take IPC requests from the
# 	   Amiga library code.

Pretty much what I had in mind.

# 	4) We should avoid trying to create an AmigaDOS compatability
# 	   library since this would probably create a complex monster
# 	   that's a bugger to maintain.

I don't have much interest in AmigaDOS compatibility, unless I
can run commercial software, al la Apple's Finder-under-A/UX.
THAT I would pay money for!  (Are you listening, Commodore?)

# 	   So, what do people think? Should we create some common
# 	   interface to /dev/amiga so a buzillion uncompatable
# 	   programming interfaces to /dev/amiga don't arise?
# 
# 	   Can C= take the lead? Maybe provide guide lines and a
# 	   very basic library, for starters, in 2.0 Amiga UNIX?
# 	   Later versions of the OS could slowly build on the
# 	   basic library routines.

Even if Commodore doesn't want to help with something like that,
I am interested in doing the design AND implementation with input
from others.

# 	   So, what can we do NOW to avoid a nasty, obfusicated,
# 	   uncooperating mass of Amiga specific code in the future??

Let's define what low-level functionality we want and how it
should work via a mailing list.  My machine isn't fit to handle
the list and Usenet News, until /dev/ser is fixed.  Can anyone
else start a mailing list for this?   

			-Jim