hubcap@hubcap.clemson.edu (Mike Marshall) (01/22/88)
Everyone knows that with adb you can find out tons of information about a running system. For example, if you type: $ adb -k /vmunix /dev/mem on my system (a 780 running ULTRIX 2.0), and then give the following adb command: swdevt/X you can list out the swap devices that are mounted. _swdevt: _swdevt: 901 ; 9=>uda device 01=>b partition disk 0 _swdevt+4: 1 ; 0=>not mounted, 1=>mounted _swdevt+8: 82a0 ; physical sectors allotted for swap device. _swdevt+c: 90e ; 9=>uda device 0e=>g partition of disk 1 _swdevt+10: 1 ; mounted _swdevt+14: 140a0 ; physical sectors allotted for swap device. _swdevt+18: 0 ) _swdevt+1c: 0 > three 0's mark the end of the swap device. _swdevt+20: 0 ) Unfortunately, the only reason I knew how to comment the above output, is because someone held my hand through it, and told me what each line meant. What if I wanted to know how to interpret the info at another offset (ttwrite for example)... the only way I can imagine ever being able to know what the *!$%##!! adb is telling me about ttywrite is to buy source and spend 9 months staying up all night studying it. Is that really the only way to ever figure out what is going on, or am I missing something? Thanks... -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap
mouse@Larry.McRCIM.McGill.EDU (der Mouse) (02/20/88)
In article <19250@felix.UUCP>, hubcap@hubcap.clemson.edu (Mike Marshall) writes: > What if I wanted to know how to interpret the info at another offset > (ttwrite for example)... the only way I can imagine ever being able > to know what the *!$%##!! adb is telling me about ttywrite is to buy > source and spend 9 months staying up all night studying it. These structures are generally declared in include files, which are usually included even with binary distribution. struct swdevt, for example, is declared in /sys/h/conf.h (at least in 4.3, and therefore presumably for your system as well). The other case you mentioned, ttwrite, isn't a data structure at all but a routine. In some cases, unfortunately, the structure is specific to one driver and can be found only in the file for that driver. These are things like dmfl_softc (which is specific to the DMF-32 driver). There isn't much to do about these, except possibly to look at source to a related dialect of UNIX (eg, 4.2BSD or 4.3BSD for Ultrix) and hope that the driver hasn't been rewritten since then. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu