On 5/19/06, Greg Price <Greg.Price at sun.com> wrote: > > I'm not really sure what is being argued here. Remember that MDB and > Solaris CAT have very different objectives and audiences - they just > happen to have an amount of overlap.
>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. MDB can analyze dumps from machines other than the one on which MDB is being run. Why isn't CAT just a user-friendliness layer on MDB? It continues to amaze me that, with a stock price less than that of a matinee movie ticket, it still apparently makes sense to maintain two separate kernel debuggers. 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. I think your Peter's comment that we're all too firmly entrenched with > no interest in working together is a little harsh. Maybe if this were the first time this issue had come up, but it's not. Sure the developers > on both sides prefer their products, but there are some design and > development constraints that limit what can be done in some areas, but > the bigger issue is lack of resources. Wow, nobody's ever hidden behind that excuse before. 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? Then you could concentrate on what you do best, namely the implementation of ::whatswrongwithmysystem-style commands, while the MDB developers concentrate on what they do best, which is the development and maintenance of the core debugger. Or we could have the exact same fruitless discussion we've been having for the past n years, with exactly the same result we've been getting for the past n years. Because that's always fun to watch. Matt Former kmdb developer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20060528/2d8fc1df/attachment.html>