On Thu, Aug 14, 2008 at 11:12:57AM -0700, Mike Shapiro wrote: > > > kernel emit a dump of a guest VM in the extant canonical savecore > > > format, keeping its virtual memory implementation details to itself. > > > Fundamentally our dump format is simply a hash table of VA -> PFN > > > mappings. It would make more sense to have the panicking dom0 > > > > I think you mean 'domU' here. > > I did mean dom0 above: that's what I was referring to, having dom0 > emit the dump of a hung domU in the appropriate canonical format.
OK, I was mislead by the "panicking" above (since nothing need be panicking at all). > > The problem is more fundamental: kernel changes in things like kmem, HAT > > structures etc. mean that existing mdb dcmds are tied to specific kernel > > revisions. As Greg mentioned, using mdb_ctf_mumble() will help here, but > > it's really a matter of policy: should future changes be careful not to > > break older crash dump processing, or do I have to go through the horror > > of an mdb_kb backport? > > > > To my mind, maintaining some level of compatibility is useful in itself. > > mdb.eng's mdb wrapper notwithstanding, it can still be troublesome. > > That isn't a new problem: that's the same problem that has always > existed. This is why mdb modules are separate from mdb itself, > and why we have the wrapper script, and the archives of mdb modules. > If you're looking at the dump you need the modules from it. I wasn't sure we had that level of guaranteed MDB module API compatibility, and I worried about mdb_ks. But I just tried it, and it even works. There's a little fiddling to get mdb_kb.so and mdb_ks.so in place, but still, it looks good. regards john
