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>

Reply via email to