Path: utzoo!mnetor!uunet!cbmvax!rutgers!umd5!trantor.umd.edu!louie
From: louie@trantor.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <2179@umd5.umd.edu>
Date: 8 Jan 88 05:18:40 GMT
References: <197@imagine.PAWL.RPI.EDU> <4918@well.UUCP>
Sender: news@umd5.umd.edu
Reply-To: louie@trantor.umd.edu (Louis A. Mamakos)
Organization: University of Maryland, College Park
Lines: 44

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!

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

It should be quite easy to hack up a simple serial.device that can redirect
to any number of alternative serial device drivers.  If anyone wants to
donate a multiport serial interface for an A2000, I'd be glad to write
write such a beast ;-) (1/2)  Please, one that can do DMA!


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

In fact, this solution doesn't slow things down at all.  When you pass the
I/O Request packet off to the REAL (old) serial.device, it will fill in the
io_Device and io_Unit (I think they're called this, off hand) to point to
itself.  Subsequent DoIO()/SendIO()/BeginIO() requests will be done directly
to the device described by io_Device in the I/O request.

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.

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.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming