Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ACTION_CURRENT_VOLUME and TD_REMCHANGEINT
Message-ID: <6995@cbmvax.UUCP>
Date: 26 May 89 15:07:45 GMT
References: <8905261114.AA08919@jade.berkeley.edu>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 40

In article <8905261114.AA08919@jade.berkeley.edu> U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) writes:
>1. ACTION_CURRENT_VOLUME. My handler gets this packet when I return
>the error ERROR_NO_DISK. Unfortunately, this packet is not documented
>in any of the things that I have (all 1.1 RKMs and Dos manuals, and
>the 1.3 autodocs). It seems that the value I return as a secondary
>result (Result2), is used in the message No disk present in unit xx.

	You should return a BPTR to your volume node on the device list
is dp_Res1, or NULL.

>2. TD_REMCHANGEINT.  I have installed a disk change Interrupt to
>notify the handler that a disk change has taken place. That works
>like it should, even though it is very scarcely documented. But I
>won't get the change Intterupt removed again, since there is
>absolutely no indication what I should put in the io_Data field
>of the TD_REMCHANGEINT IO request. I tried the two obvious things,
>i.e. the same value as with TD_ADDCHANGEINT, a pointer to the
>Interrupt structure, and a pointer to the (un-Reply()d)
>TD_ADDCHANGEINT IO request. Both do not seem to work, although
>DoIO returns 0.

	TD_REMCHANGEINT is broken currently.

>Some experimentation with a debugger has shown that the ADD request
>is the only thing on some List, which is not the List in the
>ReplyPort. Its type is also still NT_MESSAGE. So WaitIO waits forever.

	TD_ADDCHANGEINT is documented as not returning the request until
it is TD_REMCHANGEINTed.

>For now, I just Remove() the ADD request. I am certain that this is
>NOT the correct way to do things. Could someone elaborate on the
>arguments I should give with TD_REMCHANGEINT?

	Well, it's not likely to caush a crash, though it's not totally
impossible.  I'd advise Forbid(); Remove(...); Permit(); if you must do
this - and be prepared to rev for 1.4, though I'll try not to break you.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup