Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbcad!ames!amdahl!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <38256@sun.uucp>
Date: 8 Jan 88 06:40:11 GMT
References: <197@imagine.PAWL.RPI.EDU> <4918@well.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 62

In article <4918@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>[ Aren't you hungry for ASCII text now? ]
>	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 works fine for the first device, the next device you 'install' 
blows away the new serial.device, yuck. I think that serial.device should
be left alone and not bothered. Then you define a new thing in the world
that can be identified on the devs list as a serial device. DLT_SERIAL
maybe. Personally, I think that this device should have a handler associated
with it that should be associated with serial kinda things, much like disks
have handlers associated with them which do disk kinda things. The default
handler would be something AUX:/CON: like and probably ROM resident. This
thing would be announced as a new "feature" of 1.x and DOCUMENTED so that
any program could enumerate all of the serial devices just like they 
enumerate all of the disk devices. Add a series of commands you can send
to them like the CON: handler but with other info in them like baudrate
and RS232 flags, give the handler a buffer that can be read byte at a 
time and works JUST like the CON:/AUX: handlers. No one loses compatibility
because serial.device is still serial.device, manufacturers of software are
happy because a) if they don't rev their products it still works, and b)
there is an opportunity to rev the product and 'add value' which gives them
an opportunity to get some more revenue from updates. And lastly none
of the hardware manufacturers have to talk to the software writers, voila
end of problem. Hell, if we name them COMn: it will save all those PC 
converts some grief.

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

Open caches some stuff in the IORequest like the task pointer of the 
driver code. Once you've opened there wouldn't be any delays because 
all further calls would go right to the serial.device task.

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

Its a good suggestion Leo for the first add on serial port but doesn't 
have that infinite expandibility that we have grown so used to with the
other stuff in the system. Other Comments?


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.