On Sun, May 28, 2006 at 02:45:47PM -0400, Matthew Simmons wrote: > >From an architectural point of view, I don't really (and never have) see a > reason why CAT isn't just a layer on top of MDB.
I believe the original reason that MDB didn't exist, which is a pretty good one. Making scat a layer on top of MDB is not just possible but a good idea. After looking at the scat sources and talking this over with James McPherson a little, I believe we've come up with a reasonable plan to transition. There are a couple of stumbling blocks though: - sustaining need to look at pre-mdb crash dumps - 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 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. Any attempt to rewrite the world is doomed to failure. > But there's no API which you can use to control MDB? Go write one. Even > better, since you're at Sun, go find Mike, get a brain dump as to how it > should be done, and go implement that. Would be good. > >the bigger issue is lack of resources. > > Wow, nobody's ever hidden behind that excuse before. Such sarcasm :) > Isn't it possible (probable) that you'd be more effective in the long term if > you spent the time now to make MDB the core of CAT? I can't conceive of a situation where that would get funded. The above approach is the only way that even begins to be possible, and people /want/ it to happen on both 'sides'. regards john
