[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dsdp-dd-dev] debug model requirements discussion
|
Hi Pawel,
That's a very nice, concise and eloquent definition :-)
Thank you, I spent the last night working on it ;-)
BTW, one of the key words of this sentence is "family". For example, the
model you presented at the last DSDP meeting describes the command-oriented
family of backend engines. The CDI approach is better for the API-oriented
backends. This doesn't mean that your model can't be used for API-oriented
backends, but it is more convenient to use CDI in this case. At the same
time your model fits for gdb/mi-based implementation much more than CDI.
I am a little sceptical of the "universal" model approach. It either becomes
bloated, or too generic. But a modular approach could be a solution.
And it is not correct that CDI "were designed with a specific UI
representation in mind and this is what forced mixing together all the parts
of the debugger which otherwise could potentially be made modular". Current
CDI represents the standard "desktop" debug model and the modularity issue
has been on our plate for some time.
Anyway, my only intention is to avoid UI components based on the API that
fits to one model and doesn't fit to another.
Thanks,
Mikhail
----- Original Message -----
From: "Pawel Piech" <pawel.piech@xxxxxxxxxxxxx>
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Friday, June 09, 2006 2:03 PM
Subject: Re: [dsdp-dd-dev] debug model requirements discussion
Hi Mikhail,
(my comments inlined)
Mikhail Khodjaiants wrote:
Pawel,
As far as your second question, do you feel that the requirements listed
are too broad and/or too ambitious?
For me the definition of "a debug model" (not "the debug model") in this
context is an abstraction in form of API that describes a family of
debugger
engines. Combined with the implementation that adapts the model into the
Eclipse debug platform it will allow clients to integrate backend
debuggers
into Eclipse.
That's a very nice, concise and eloquent definition :-)
The obvious example of a debug model is the platform debug model, which
works very well for Java debuggers, but doesn't work for embedded
purposes.
As you know it used to be the only debug model supported by Eclipse. Now
it's one of the possible backend models.
So, IMO we shouldn't try to come up with a universal API and make the UI
components heavily depend on it. Instead we should focus on the design of
the UI component that can work with various models. Current platform
views
are good examples of what we need.
I absolutely agree with you on the point that writing the debug model API
to match the desired UI representation turned out to be a mistake. I see
two main problems with it:
1) with different debuggers, someone will want a different UI
representation,
2) it doesn't allow the debugger implementation to be modular (at least
not without having an adapter layer for the APIs).
To address problem #1, we now have flexible hierarchy views, which by
itself is a good mechanism for making small changes on top of the existing
Platform model layout. But for large extensions, flexible hierarchy
leaves the model design completely up to the implementor, which is good,
but it leaves the implementor with a pretty large burden. Also using
flexible hierarchy, doesn't provide a standard API of accessing this data
for purposes other than populating views.
As far as problem #2, I think at this point it's a completely open
question.
I have never been a fan of Chairman Mao, but I would like to quote him
here:
"Let a hundred flowers bloom." :). I believe this expression describes
the
whole Eclipse ideology very well.
These are just general thoughts on the role of a debug model in Eclipse.
Regarding the requirements, my question is how to interpret the
following:
Even though many aspects of embedded debugging is unique to a given
vendor/target configuration, etc, all of these debuggers share some
common
functionality found in standard debuggers (reading/writing memory, run
control, stack retrieval, expression evaluation, etc).
a.. Debug model should define a set of public APIs to access common
debugger functionality, either by supporting existing APIs (Platform,
CDI,
JDI) or defining new ones.
b.. If new APIs are defined, the model should have the ability to
support
legacy APIs: Platform, CDI, etc.
Is this is supposed to be a universal API that will replace the platform
debug model, it is too ambitious. As you know, the first attempt failed
and
there is no guarantee that another attempt will not fail again.
If it is not a proposal for a universal API then it is confusing and
needs a
clarification. I don't think Darrin is planning to abandon the platform
API
in JDT, neither the CDT team has plans to drop CDI. Moreover, we are
considering to improve it and take advantage of the new implementation of
the debug views.
I guess to answer the key question: I do believe there is a place for a
"universal" API for debuggers. But I don't think it can be a fixed set of
interfaces that will satisfy all debugger implementors for all time.
Instead I think the problem can be addressed by creating a framework where
modules are assembled together to form a complete implementation of a
debugger. Some modules can implement published APIs for most standard
debugger functionality like what the platform debug model covers. Other
modules can implement more specialized APIs, dealing with
technology-specific capabilities, while still other modules could be
completely vendor-specific and proprietary. Of course this is not to say
that you can't have a monolithic implementation of a debugger, but at
least you shouldn't be forced into it by the API design.
I really don't know if CDI or platform debug model could be morphed to
meet such a design goal. I have to admit though that I am rather
skeptical, because these APIs were designed with a specific UI
representation in mind and this is what forced mixing together all the
parts of the debugger which otherwise could potentially be made modular.
This doesn't mean that CDI or platform debug model should or could be
"abandoned". They work well in many if not most situations, and there is
a lot of client code as well as debugger implementations that are written
against them. That's why I said that if these models cannot be made to
meet the stated requirements, the new universal model that is to be
invented needs to support them at least through a compatibility layer.
Cheers
Pawel
Regards,
Mikhail
----- Original Message -----
From: "Pawel Piech" <pawel.piech@xxxxxxxxxxxxx>
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Thursday, June 08, 2006 7:56 PM
Subject: Re: [dsdp-dd-dev] debug model requirements discussion
Thank you Mikhail,
Good point. I guess I assumed that "Debug Model" implies the objective
of a discussion, but it obviously doesn't. I added an objective stated
as
To define a set of APIs and a mechanism for extending these APIs to
allow various debugger implementations to:
1. drive content of debug views,
2. allow users to perform operations to change the state of the
debugger,
3. allow 3rd party tools and standard clients to interact with
debugger.
As far as your second question, do you feel that the requirements listed
are too broad and/or too ambitious?
Cheers
Pawel
Mikhail Khodjaiants wrote:
Hi Pawel,
I've had a quick look at the requirements and I think the objective
part is missing.
Reading the requirements one can get the impression that you are
proposing to come up with a universal API and implement debug views
and other UI components on the top of it. Is this correct or not?
In any cases, the goal should be identified from the beginning.
Thanks,
Mikhail Khodjaiants
----- Original Message ----- From: "Pawel Piech"
<pawel.piech@xxxxxxxxxxxxx>
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Thursday, June 08, 2006 2:18 PM
Subject: [dsdp-dd-dev] debug model requirements discussion
Hi all,
Based on the information I gathered so far, I listed the DSDP
requirements for a debug model on the twiki page:
http://wiki.eclipse.org/index.php/DSDP/DD/DebugModel
I gave up on the hypothetical debugger example, or on trying to
collect
all the use cases to support all the requirements. Given how in this
group everyone seems to rather familiar with the problem space, it
might
be easier to just come up with use cases as needed to justify specific
requirements.
-Pawel
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev