On 5/28/06, John Levon <john.levon at sun.com> wrote: > > I believe the original reason that MDB didn't exist, which is a pretty > good > one.
That's true. MDB has been out now for what, three releases? At what point does this justification lose its weight? > - sustaining need to look at pre-mdb crash dumps What does that mean at this point -- 2.6? I was under the impression that S7 support was not long for this world, to say nothing of 2.6. At some point surely you can just say that you're not doing further development of Solaris CAT for a given release. Given its age, surely 2.6 is one of those releases for which up-to-the-second debugging support isn't critical. - they also need a convenient way to automatically adapt to the kernel > version > being investigated. The kernel bits of MDB aren't really able to do that > (yet) > - interaction with MDB isn't really there, as you mention > - there's no resources to do it Are there resources for adding new features to Solaris CAT? If there are, then clearly the issue isn't one of resources per se, but rather of desire or will. > Considering all that, the sensible approach seems to be to start off by > adding > a simple backend to scat's ksh core which can interact with [the correct > version of] mdb's command line. Then, each module of scat can be replaced, > as > time allows, with an mdb module or dcmd in a piecemeal fashion. This isn't > at > all hard to do. The old scat source for that module would linger on for > older > kernels. But eventually, essentially all the duplicate code in scat could > be > replaced with MDB-based code. Exactly. And while we're on the subject, can we *please* get Solaris CAT renamed? The current acronym is an embarrassment. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20060529/9b7982c5/attachment.html>
