Hi Mikhail,
(comments below)
Mikhail Khodjaiants wrote:
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 think we're in agreement here :-) CDI, and platform debug model APIs
are, more specifically, object-oriented sets of interfaces where the
relationship between the objects is built into their structure. For
example:
IDebugTarget (references)-> IThread ->
IStackFrame -> IVaraible -> IValue
Extendability is accomplished by sub-classing individual interfaces and
adding additional types and methods that can stem from the sub-classed
object. This allows small extensions which are easy and cheap to
implement, but which cannot change the fundamental structure imposed by
the base interfaces.
What I would like to suggest as a way of avoiding this problem, is to
define the interfaces more around the functionality that they represent
and less around the relationships between the elements that make up the
debug model. This requires the API to be more flat and C-like, but
that's not necessarily a bad thing. Something that would look like:
IRunControl {
resume(ExecutionContext);
canResume(ExecutionContext);
...
}
IOS {
Process[] getProcesses()
Process createProcess(...)
killProcess(Processs)
...
ExecutionContext getThreads(Process);
...
}
IKernel {
ExecutionContext getSystemContext();
ExecutionContext[] getKernelThreads();
...
}
With this kind of API design, there would still be dependencies between
interfaces. But given the knowledge we have a about the debuggers out
there, we can design these dependencies so that almost any back end can
be implemented without the need for having a lot of interfaces that are
stubbed just to satisfy the API. It should also be easy for debugger
vendors to add modules which are unique to their architecture.
Unfortunately what is missing from this solution is how the model data
should be presented to the user in various debug views. You could
simply write content/label/model proxy providers for each debugger
implementation and each debugging configuration. But I believe there
is room for infrastructure which would allow the UI providers to be
driven by a script or data file, and that is where the idea of using a
command-like protocol came from. Still, I hope that this can be viewed
as a separate problem to solve at a later time or concurrently.
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.
I apologiese. I shouldn't presume what was the motivation behind the
design was since I wasn't there.
Cheers
Pawel
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|
