Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!wanginst!ucadmus!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Dual porting UDA50 drives under 4.2
Message-ID: <2210@umcp-cs.UUCP>
Date: Thu, 3-Jan-85 17:05:04 EST
Article-I.D.: umcp-cs.2210
Posted: Thu Jan  3 17:05:04 1985
Date-Received: Sat, 5-Jan-85 23:42:47 EST
References: <6911@brl-tgr.ARPA>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 23

> Handling the online to another controller end message, all by itself,
> seems easy.  Although I did not examine the changes required to support
> the multi-porting in the 4.2 BSD driver, I don't believe it would be too
> difficult to adopt a simple strategy of sleeping, and retrying the
> operation later.

If by ``sleeping'' you mean calling sleep(chan, pri), then no, this
should not be done.  The off line error is detected at interrupt level
and with some random process (if any) running.  Ideally, the controller
would give another interrupt when the drive came on-line; you could
then set a flag that says ``this drive is at the Bahamas but I'm
getting it now'' and simply queue any new operations until it comes
back.

If you can't get the controller to announce the presence of the desired
drive, then you'd have to resort to timeout calls to check it every so
often, or something like that.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland