lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/15/90)
In <16014@s.ms.uky.edu>, kherron@ms.uky.edu (Kenneth Herron) writes: > >My problem is that for one solid week now I've been unable to find one >shred of a way to see what driver is controlling what device. I can >follow the exec list of devices to find trackdisk.device, no problem. >I can follow the device list (SER:, PRT:, et al) to find DFx:, no >problem. But no way to determine "trackdisk.device controls these >devices" or "this device is controlled by trackdisk.device". Here's a fragment of something I did a while ago. It looks for devices by name (DF0:, etc.), and throws away assigned names, etc. You should be able to modify it easily. If you are using C, it shouldn't be too tough to translate, and at the least, it will show you the path to the info you need. It's an early effort, so don't laugh. :-) getdev move.l dos,A0 ; Get dos base move.l dl_Root(A0),A1 ; find the root node move.l rn_Info(A1),A0 ; get the DosInfo struct add.l A0,A0 ; convert from BCPL add.l A0,A0 move.l 4,a6 call Forbid move.l di_DevInfo(A0),A1 ; get pointer to device list 1$ add.l A1,A1 ; it's BCPL, so convert. add.l A1,A1 move.l A1,infosave ; need this later move.l dl_Type(A1),D0 ; check the type... bne 2$ ; It is not a device. move.l A1,A0 move.l dl_Name(a0),a1 ; get pointer to device name add.l a1,a1 ; convert to real pointer add.L a1,a1 lea namesave,A0 ; point at name buffer sub.l loopreg,loopreg move.b (a1)+,loopreg ; gets BSTR length sub.l #1,loopreg ; adjust for loop 3$ move.b (a1)+,(a0)+ ; get the actual name dbra loopreg,3$ move.b #':',(a0)+ ; tack a colon onto the end move.b #0,(a0)+ ; and null terminate it move.l #namesave,a0 move.l argptr,a1 move.l arglen,loopreg sub.l #1,loopreg cmp.b #0,(a1) beq 2$ 4$ cmp.b (a0)+,(a1)+ ; compare arg name with devname dbne loopreg,4$ subq #1,a0 cmp.b #0,(a0) bne 2$ ; if we get here, we have found a device with the same name ; as we were passed in the command line. move.l infosave,a0 ; recover device node pointer move.l dn_Startup(a0),a0 ; get fssm struct address adda.l a0,a0 ; convert from BCPL adda.l a0,a0 move.l a0,fssmsave ; cache it move.l fssm_Environ(a0),a0 ; get disk environment struct address adda.l a0,a0 adda.l a0,a0 ; Gather all data for partition we want to look at. movem.l d0-d7,-(sp) ; save everything move.l de_BlocksPerTrack(a0),d0 move.l de_Surfaces(a0),d1 move.l de_LowCyl(a0),d2 move.l de_HighCyl(a0),d3 move.l d0,secstrack move.l d1,numheads move.l d2,lowcyl move.l d3,highcyl move.l d1,d4 ; d4 = numheads mulu d0,d4 ; d4 = secs/cyl move.l d4,secscyl move.l d3,d5 ; d5 = highcyl sub.l d2,d5 addq #1,d5 ; d5 = numcyl move.l d5,numcyl mulu d4,d5 ; d5 = numsecs move.l d5,numsecs lsr.l #1,d5 ; d5 = root btst.b #0,numsecs+3 beq.s 7$ addq #1,d5 7$ move.l d5,root mulu d2,d4 ; d4 = base sector for partition move.l d4,base lsl.l #8,d4 ; d4 = base byte offset for partition lsl.l #1,d4 move.l d4,basebytes movem.l (sp)+,d0-d7 ; *** here's the part you want *** move.l fssmsave,a0 move.l fssm_Device(a0),a0 ; get pointer to device driver name adda.l a0,a0 ; and convert it (sigh) adda.l a0,a0 lea devname,a1 sub.l loopreg,loopreg move.b (a0)+,loopreg ; get length of name subq #1,loopreg ; adjust for loop 6$ move.b (a0)+,(a1)+ ; move name dbra loopreg,6$ move.b #0,(a1) ; and null terminate t bra.s 5$ 2$ move.l infosave,A1 move.l (A1),A1 ; get the next one move.l A1,D0 ; do this for a zero test bne 1$ ; is this the last file? move.l #0,namesave 5$ move.l 4,a6 call Permit rts ---------------------------- -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
kherron@ms.uky.edu (Kenneth Herron) (09/16/90)
I hope somebody out there can help me with a problem that's driving me crazy. I'm trying to write a program that operates on units managed by trackdisk.device (ie, floppy disks). Part of the command line would specify which drive(s) to operate on. For the user's convenience I want to allow names like DF0:, WorkBench:, SYS:, etc. In other words, the user may specify an actual drive name, a volume that's in a disk drive, or even an assign to a directory on a floppy, and my program should correctly determine which drive to act on. SOOO...I have to make sure, once I've "dereferenced" the given name to an actual device like DF0:, RAM:, or whatever, that the referenced drive is actually controlled by trackdisk.device, without hard-coding names like DF0: into the program--for instance, if the user mounted DF0: and DF1: as A: and B:. My problem is that for one solid week now I've been unable to find one shred of a way to see what driver is controlling what device. I can follow the exec list of devices to find trackdisk.device, no problem. I can follow the device list (SER:, PRT:, et al) to find DFx:, no problem. But no way to determine "trackdisk.device controls these devices" or "this device is controlled by trackdisk.device". My last good idea was to open trackdisk.device and extract the MsgPortPtr from the initialized ioRequest structure, with the intent of comparing it to the MsgPortPtr in the device entry for DF0:. But The MsgPortPtr from trackdisk.device was null, a value deliberately written there by opendevice(). (How can this be right? Once you open a device you're supposed to be able to send it messages, no?) Any help would be appreciated... Kenneth Herron
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/27/90)
In <14697@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1980@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >> lea namesave,A0 ; point at name buffer >> sub.l loopreg,loopreg >> move.b (a1)+,loopreg ; gets BSTR length >> sub.l #1,loopreg ; adjust for loop >>3$ move.b (a1)+,(a0)+ ; get the actual name >> dbra loopreg,3$ >> move.b #':',(a0)+ ; tack a colon onto the end >> move.b #0,(a0)+ ; and null terminate it > > Note that entries on the Dos Device list do NOT have ':'s following >them (they are BSTR names followed by a null byte). Right.. that's why I tack one on there when I save the name for printing to the screen. > Also, before examining the startup field, etc, you must check that >the node is of type DLT_DEVICE. Good idea. I'll do that next time I need to use the code. > Also you must handle Startup values that >are NOT pointers - for example, SER:, PAR:, PRT: take small integers there. Hmm... never noticed that, but then I wasn't looking. I'm a little puzzled as to what the 'small integers' do. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jesup@cbmvax.commodore.com (Randell Jesup) (09/28/90)
In article <1980@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > lea namesave,A0 ; point at name buffer > sub.l loopreg,loopreg > move.b (a1)+,loopreg ; gets BSTR length > sub.l #1,loopreg ; adjust for loop >3$ move.b (a1)+,(a0)+ ; get the actual name > dbra loopreg,3$ > move.b #':',(a0)+ ; tack a colon onto the end > move.b #0,(a0)+ ; and null terminate it Note that entries on the Dos Device list do NOT have ':'s following them (they are BSTR names followed by a null byte). Also, before examining the startup field, etc, you must check that the node is of type DLT_DEVICE. Also you must handle Startup values that are NOT pointers - for example, SER:, PAR:, PRT: take small integers there. Under 2.0, all of this is much easier to do. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (10/01/90)
In <14764@cbmvax.commodore.com>, andy@cbmvax.commodore.com (Andy Finkel) writes: >In article <2055@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>> Also you must handle Startup values that >>>are NOT pointers - for example, SER:, PAR:, PRT: take small integers there. >> >>Hmm... never noticed that, but then I wasn't looking. I'm a little puzzled as >>to what the 'small integers' do. > >SER:, PAR: and PRT: are the same handler; the startup value is used >to indicate how you called it. > >(See my port-handler source from the 1988 DevCon disks for more details) Ahh! You clever devils you! Thanks Andy. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
andy@cbmvax.commodore.com (Andy Finkel) (10/01/90)
In article <2055@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >> Also you must handle Startup values that >>are NOT pointers - for example, SER:, PAR:, PRT: take small integers there. > >Hmm... never noticed that, but then I wasn't looking. I'm a little puzzled as >to what the 'small integers' do. SER:, PAR: and PRT: are the same handler; the startup value is used to indicate how you called it. (See my port-handler source from the 1988 DevCon disks for more details) andy >-larry -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Nothing is as permanent as a temporary kludge." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.