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