Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!wanginst!ucadmus!harvard!seismo!brl-tgr!tgr!dave@RIACS.ARPA
From: David L. Gehrt 
Newsgroups: net.unix-wizards
Subject: Re: Dual porting UDA50 drives under 4.2
Message-ID: <6991@brl-tgr.ARPA>
Date: Fri, 4-Jan-85 12:46:46 EST
Article-I.D.: brl-tgr.6991
Posted: Fri Jan  4 12:46:46 1985
Date-Received: Sun, 6-Jan-85 00:03:15 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 23


When a UDA50 device "unit online" to hosta, no longer is in that
condition, it is supposed to notify the controllers, who in turn notify
the hosts via some Available Attention Message.  The real fly in the
ointment seems to me to be, that as I read the stuff, there is *no* way
to guarantee that the other host will ever release its grip on the
device, and the MSCP protocol provides no way to force the release, or
even request it.  This would really screw things up if you tried
swapping on a shared device (assuming you could overcome the systemic
problems associated with shared swapping, or even if the swap partition
is not shared).

As far as sleeping, I guess I haven't quite earned my wizards wand
(spear, spurs, flame thrower ?) drivers do sleep from time to time, I am
sure I have seen it.  The context switch results in a new cpu status
word and things hum along until the wake up condition when the process
is awakened at interrupt priority and away it goes.  There are of
course other mechanisms for delaying the device access under these
circumstances so the bottom line is that it is a doable thing, but
still of dubious utility.

dave
----------