Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!mcnc!gatech!hao!boulder!sunybcs!bingvaxu!leah!itsgw!imagine!pawl21.pawl.rpi.edu!jesup
From: jesup@pawl21.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <201@imagine.PAWL.RPI.EDU>
Date: 9 Jan 88 01:58:03 GMT
References: <197@imagine.PAWL.RPI.EDU> <4918@well.UUCP>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 98

In article <4918@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>	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....

Hmm, I thought I was using hardwood... :-) :-)  Actually, I'm more interested
in making it transparent to the user than to the programmer, though it would
be nice for that to be fairly transparent as well.

>	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).

For old programs, yes.  The current mechanism that programs use (opening
serial.device unit 0) is insufficient for the future.  Part of this extension,
both Bryce and I agree (I believe) is ways to make old programs that think
they are opening the internal port actually open another port.  

>	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.

Sorry, this is a kludge, and will not work if someone installs boards with
serial ports from multiple manufacturers.
I propose that for new programs that use the serial port, the following
be used:
		First, try to open a serial port with the device you
	want (Modem, Laserwriter, whatever) via the mapper.device  The
	IORequest passed in the OpenDevice, is shown in a previous message,
	It has a pointer to an initialized IOExtSer structure, flags, and
	the name of the thing you want to open.  If the OpenDevice fails
	because the person doesn't have it (and probably has no extra
	serial ports) then it should do an OpenDevice using the IOExtSer
	of serial.device, unit 0.  It would look like this:

		<set up IOExtSer as always>
		IOExtMap.Serial = &IOExtSer;
		IOExtMap.Flags  = MAPFLAGS;
		IOExtMap.Name   = "Modem";
		if (OpenDevice("mapper.device",0,&IOExtMap,0))
			if (IOExtMap.Error)
				/*mapper exists but can't open desired device*/
				report some error
			else
				if (OpenDevice("serial.device,0,&IOExtSer,0))
					report error
		/* If we get here without error, we can use IOExtSer */

	Not all that much different than now.  Remember, I am assuming
	a seperate way of rerouting requests for serial.device unit 0 from
	old programs.  (Fairly easy to do)
	Among the many reasons I prefer a name mapper to using higher unit
	numbers is that to the user of a program, 'modem' is more meaningful
	than 'unit 4'.  Hopefully, a user of a program that used this wouldn't
	ever have to reconfigure his terminal program to tell it which unit
	the modem is on.  Once the system has been told, all programs can find
	it.

>	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.

A lot of programs depend on the correct handling of IOF_QUICK.  Also,
IOF_QUICK can be MUCH faster, and allows programs to do 9600 baud vt100.

>	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?

Messing with exec lists is utterly EVIL.  My proposals stay within the 
documented usage of routines.

>_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
>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")

P.S.  I am cross-posting this to BIX.

     //	Randell Jesup			Lunge Software Development
    //	Dedicated Amiga Programmer	13 Frear Ave, Troy, NY 12180
 \\//	lunge!jesup@beowulf.UUCP	(518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup)