Standards for /dev/amiga and Co.
Rob Healey
rhealey at digibd.com
Mon May 20 15:00:25 AEST 1991
First, for the many Dorephores and pedants out there who have gotten
ruffled feathers over my use of the word Amix in place of the
rather wordy Amiga System V Release 4.0 Version 1.x UNIX I
shall use the phrase "Amiga UNIX" from now on despite bitter
protests from my fingers. B^).
Now, up on my philosophical soap box I go:
I realized today that our AmigaDOS brethern, and sisteren, have
one very important advantage over us poor Amiga UNIX souls:
Standard methods, API if you wish, of accessing and controlling
Amiga hardware so nasty interference doesn't take place betwix'd
tasks.
What we need is a standard set of library functions, maybe in
/usr/lib/libamiga.{so,a} for controlled and simplified access
to /dev/amiga. If there isn't a standard put out by C= then
all of us will end up creating oodles of different "standards"
and that will require grand reunification at some painful point
in the future. 2.0 seems to be a good place to start a standard
for safe access to /dev/amiga by multiple programs.
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?
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.
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.
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. Rather, a basic set of functions
should be drawn up and put into the library. Obviously
graphics and sound are the two main catagorys. Under sound
we have music, noise and speech. Under graphics, the
various modes and graphic operations. Initially, create
the most basic functions that can be used to build
complex stuff. Maybe make it, "object oriented". If we
can define the basics for 2.0, then later releases can
add increasingly higher level functionality.
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.
X provides some graphic solutions to problems but it
seems like a less bulky way of accessing Amiga hardware
should be available. Plus, there's no sound, music or
speech capability in X.
So, what can we do NOW to avoid a nasty, obfusicated,
uncooperating mass of Amiga specific code in the future??
Pondering yet more Amiga mysterys,
-Rob
--
Rob Healey rhealey at digibd.com
Digi International (DigiBoard)
Eden Prairie, MN (612) 943-9020
More information about the Comp.unix.amiga
mailing list