Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ptsfa!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <4918@well.UUCP>
Date: 6 Jan 88 22:23:59 GMT
References: <197@imagine.PAWL.RPI.EDU>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: PSA (Poor Security Administration)
Lines: 42

[ Aren't you hungry for ASCII text now? ]

	Bryce and Randall seem to be beating each other over the head with
foam bats regarding extending the serial.device to support multiple devices
and make it transparent to the programmer.  If I might make a suggestion....

	If I were going to do this, I would try to make it as transparent as
possible, with a minimum of skullduggery.  Programmers (and indeed, existing
programs) should not be able to tell the difference, and should run
identically (if they were written correctly).

	Unit 0 should remain the internal serial port.  Units 1 - MAXINT
should represent external ports.  Exactly which ports they'd be would be
vendor-specific.  The hardware expansion would come with a disk with an
installation program.  The installation program would do the following:

	Find the existing serial.device file in the DEVS: directory.  Rename
the file to something else (intser.device?), and patch the file itself to
reflect this change.  Next, copy into DEVS: the new serial.device, which
knows about the external ports.

	This new serial.device also knows about the "old", renamed serial
driver.  When a program opens the serial.device, the vendor's handler checks
the unit number.  If it's zero, it opens the old one.  The device would then
check subsequent I/O transactions to see if they are intended for unit zero.
If so, it just re-posts the transaction to the original driver, who will
process it and return it to the calling program.

	I project that this would slow down internal device transactions
minimally, and is sufficiently transparent that it wouldn't cause anything
untoward to happen.  The only icky thing I can think of is that IOF_QUICK
transactions might get mucked up.

	I think this is a better approach as it avoids going behind Exec's
back (it doesn't mess around with Exec's (probably private, don't-mess-with-
these) lists).  Comments?

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor