Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!trantor.umd.edu!louie
From: louie@trantor.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.amiga
Subject: Re: Serial port expansion
Message-ID: <2185@umd5.umd.edu>
Date: 11 Jan 88 04:27:22 GMT
References: <197@imagine.PAWL.RPI.EDU> <4918@well.UUCP> <22440@ucbvax.BERKELEY.EDU> <3113@cbmvax.UUCP> <22472@ucbvax.BERKELEY.EDU>
Sender: ris@umd5.umd.edu
Reply-To: louie@trantor.umd.edu (Louis A. Mamakos)
Organization: University of Maryland, College Park
Lines: 25

In article <22472@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes:

>I'll give that a hesitent "Don't think so".  I'm assuming CloseDevice()
>looks at io_Device and fires off a Close to the proper device.  The device
>would decrement the count and perhaphs become expungeable.

It appears that CloseDevice() dives through the io_Device field in the I/O
reqeust, so I don't think you have to do anything weird with CloseDevice, 
assuming you keep the OpenCount adjusted properly when you do the open and
"vector" off the the alternate device drivers.

>
>I bounced on an attempt at disassembling CloseDevice().  It has some funky
>ram patch that looks to be either setting up a frame pointer or a Global
>Vector.  Ick!

I'm not sure, but remember that when you do a CloseDevice(), the
Expunge entry point to the driver is called as well as the Close entry
point.  That might be what's going on.




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