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