Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!leah!itsgw!imagine!pawl19.pawl.rpi.edu!jesup
From: jesup@pawl19.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <204@imagine.PAWL.RPI.EDU>
Date: 12 Jan 88 03:31:25 GMT
References: <197@imagine.PAWL.RPI.EDU> <4918@well.UUCP> <2179@umd5.umd.edu>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 53

In article <2179@umd5.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes:
>In article <4918@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>	Unit 0 should remain the internal serial port.  Units 1 - MAXINT
>>should represent external ports.
>
>Yes! Yes!  Don't make the system more complicated at this level, please!

	As I have said before, these higher unit numbers have no meaning
to the user, especially if you have multiple serial port expansions.
And my proposal for using a mapper is hardly at all more complicated than
the current method, and in fact is probably easier than having a requester
to ask the user what unit number to open (which the user might not know
either).  See the example code in a previous message to open a serial
device via the mapper.

>>	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 don't really agree that the vendor's serial device driver should be doing
>this;  I think a seperate program should.  What if I have more than one
>vendor's serial board in my system?  That at least 3 serial device drivers.

	Exactly!  That's why I say we should use a mapper that opens the
appropriate serial device for you.

>The neat thing 'bout this solution is that the drivers for units 1-n don't
>have to be resident in memory until/unless they are used.  You can be clever
>in this 'clearinghouse' serial.device, and have it read a configuration 
>file that maps serial.device unit numbers into (device,unit) tuples.

	This is what my mapper is doing.  Using the mapper, you also don't
have to load any drivers until needed.  Also, you can do it without having
to have a 'mountlist-type' config file around, all the user needs to do
is to drag an icon over into his expansion drawer.

>I believe that this symbolic naming should be done at a higher level where
>I can ignore it, and not have to pay the extra overhead to fool with it.

	As I said, the overhead can be made almost nil, and I think a tiny
amount of overhead (only on open, plus 5-10 standard lines of code in
programs) is well worth it for an easier to use, more intuitive, and readily
expandable method of serial port expansion.

>Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU

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