U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (05/26/89)
I am currently busy writing a file system handler for messydos
diskettes, and I am having two problems about the things in the
subject line.
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.
So if you return error 206 (ERROR_ACTION_NOT_KNOWN), you get a
requester saying No disk present in unit D9. ('0' + 206/10 == 'D')
I wonder what I must return in Result1. As long as I make it zero
(NULL), it works. But maybe the intention is that I return a BPTR
to the currently inserted VolumeNode there?
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.
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.
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?
Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)->
Olaf.Seibert;
Astounding News! By Express Via Norfolk! OS+2 is a trademark of
The Atlantic Crossed in Three Days! Olaf 'Rhialto' Seibert
[E.A. Poe, 1844] U211344@hnykun11.bitnetjesup@cbmvax.UUCP (Randell Jesup) (05/26/89)
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
U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (06/01/89)
(Sorry if you see this twice. I never saw it back and got no replies)
----------------------------Original message----------------------------
I am currently busy writing a file system handler for messydos
diskettes, and I am having two problems about the things in the
subject line.
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.
So if you return error 206 (ERROR_ACTION_NOT_KNOWN), you get a
requester saying No disk present in unit D9. ('0' + 206/10 == 'D')
I wonder what I must return in Result1. As long as I make it zero
(NULL), it works. But maybe the intention is that I return a BPTR
to the currently inserted VolumeNode there?
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.
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.
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?
Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)->
Olaf.Seibert;
Astounding News! By Express Via Norfolk! OS+2 is a trademark of
The Atlantic Crossed in Three Days! Olaf 'Rhialto' Seibert
[E.A. Poe, 1844] U211344@hnykun11.bitnet