crash@ckctpa.UUCP (Frank J. Edwards) (08/21/90)
I've been doing some tinkering with device handlers lately, and so far each time I write a new version to test I have to change the name of the device in my temporary MountList and mount the new device, i.e. change TAP1: to TAP2: in file Tape-ML 1> mount tap2: from tape-ml I've been using Dillon's ramdisk example and he comments on clearing the dn_Task field so that Dos will startup a new task later on if necessary instead of leaving the current one hanging around. But there's no clue about removing it entirely except at the beginning of the code where he adds a DT_VOLUME entry to the device list so that WB will see his ramdisk. Its in that section of code that the DosNode is examined and a new DeviceNode is created for the ramdisk. Well, if anyone has any answers I'd like to hear from you. There are others in my local Amiga users group who would also like to know... ----- Frank J. Edwards, | "Be different! Join the American 2677 Arjay Court | Non-Conformist Society TODAY!" Palm Harbor, FL 34684-4505 | -- the above message is a public service Phone: (813) 786-3675 | -- bulletin brought to you by this station
dillon@overload.Berkeley.CA.US (Matthew Dillon) (08/24/90)
In article <082090.121327@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >I've been doing some tinkering with device handlers lately, and so far >each time I write a new version to test I have to change the name of >the device in my temporary MountList and mount the new device, i.e. > > change TAP1: to TAP2: in file Tape-ML > > 1> mount tap2: from tape-ml > >I've been using Dillon's ramdisk example and he comments on clearing >the dn_Task field so that Dos will startup a new task later on if >necessary instead of leaving the current one hanging around. But >there's no clue about removing it entirely except at the beginning >of the code where he adds a DT_VOLUME entry to the device list so >that WB will see his ramdisk. Its in that section of code that the >DosNode is examined and a new DeviceNode is created for the ramdisk. Your DOS handler process must set up the dn_Task field in its DosNode structure to point to itself if it does not wish a new process started up on every reference. Something like a RAM: disk wants to do this. Something like a console device would want to keep the field NULL to force a new process be started up on every reference. You MUST use reentrant code for DOS handlers in most cases, either to allow multiple invocations or to handle the exit case when using the main() or _main() entry point. If you understand enough about the compiler you are using to do away with any kind of standard startup then you can usually get away with a Forbid() just before exiting. In anycase, what happens is that your process may exit and free all of its resources, but the mount entry still exists in ram. You can use 1> Assign device: REMOVE To remove the mount reference (this wastes a little memory). This assumes your device process exits when not in use. For any device process that does not exit when not in use, while the reference can be removed with the above command the process will still exist, wasting memory though not any CPU. P.S. my old RAM disk example is somewhat buggy in respect to exiting when not in use, there is a window of vulnerability. This is why, especially, you want to make the code reentrant. It allows one instance of the process to be in the middle of its exit sequence while another instance is starting up. -Matt >Well, if anyone has any answers I'd like to hear from you. There are >others in my local Amiga users group who would also like to know... >----- >Frank J. Edwards, | "Be different! Join the American -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA