Thanks all. I just wanted to see if this was already done before I start typing. Ideally, I think I should be able to use ANY file with mdb, and if I want to load some module(s) that contain commands that may not work with the file in question, that's my problem. I may just try to work around something like:
mdb /dev/ksyms /dev/rdsk/c1t0d0s0 Currenly, mdb complains about not being able to find the 'platform' string. Something I used to do with the old crash(1) command was to change it to ignore stuff it couldn't find. This was helpful with (slightly) corrupted core files. Of course, doing this with mdb may end up taking longer than using the code in kmt_name_to_ctf() as suggested below. (So I ignore the 'platform' string, then what does mdb complain about next?). At any rate, this shouldn't take too long, so I'll post what I've done when I'm finished. By the way, what I am really trying to do, is to understand the layout of zfs on disk. The white paper about zfs on-disk format, while quite good at explaining the architecture of ZFS, doesn't really give me a good idea of where things are physically on the disk (except the nvlist, labels, and uberblocks). Given that I can find those things on the disk, I should be able to find dnodes, blk_dva's etc., but I have had a difficult time matching what I see when I look on the disk at the offsets specified by a blk_dva, and the data that is at that offset. In other words, I go to a blk_dva offset, dump out the data, and it is sometimes what I expect (file data), but other times I have no clue what I am looking at... (dnode, dsl, indirect block, ???). max Michael Shapiro wrote: >> On Sun, Jan 28, 2007 at 05:21:46AM -0800, max at bruningsystems.com wrote: >> >> >>> I want to be able to use ::print some_type_in_kernel with the raw disk >>> as a target. Has anyone already done this, or do I need to write code? >>> >> In an ideal world, you could do: >> >> # mdb /dev/dsk/c1t1d0s0 >> >>> ::load -g amd64/mdb_ks.so >>> ::load -g amd64/ufs.so >>> ::print DMOD`ufs`ufs_owner_type >>> >> But the DMOD syntax is only supported by kmdb, and the rawfile target doesn't >> implement ->t_name_to_ctf(). If you want to play around, you could try >> looking >> at the DMOD code hanging off kmt_name_to_ctf(), and implement it in >> mdb_ctf.c:name_to_type() (before we call mdb_tgt_name_to_ctf()). Not positive >> that'll work, but it's worth a go. >> >> regards, >> john >> > > Yes, the model should be that in order to use it with the rawfile target > you have to manually load some CTF container, either a stand-alone file > or from an ELF file like the kernel or whatever. Fundamentally this should > be a common service at the target layer, since even when you are using > proc or whatever you may want to manually load something to supplement > some missing types. > > -Mike > >
