RE: [cdt-dev] [DSF] SessionType

["Andy Jin" <AJin@xxxxxxx>]

>From my experiences working on the Jtag debug launch, and now working on
migrating our debug framework to DSF, I found out that DSF-GDB is a
relatively good example of learning how to "instantiate" DSF services.
DSF itself is such an abstract framework that without a concerect
example it's not easy to understand how it works. I mainly follow what
DSF-GDB does and customize while I need - that includes copying its
codes and modify.

To be fair, DSF-GDB was not designed to fit in every environment. It's
generic and does the minimum to work with (mainly) Linux GDB. I think
every DSF adaptor needs to come up with his/her own launch delegate and
maintain it.

Being said that, as more and more people migrating to DSF and taking
DSF-GDB as the model, it's now time to expand DSF-GDB from an generic
example to be framework-like archetecture so we don't have to copy codes
from it. I couldn't agree more on componentizing DSF-GDB so the
definition of SessionType and the steps in FinalLaunchSequence can be
re-used in a manage-able way, even the ServicesLaunchSequence can be
re-archetected too.

- Andy

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam
Sent: July 8, 2010 1:21 PM
To: 'CDT General developers list.'
Subject: RE: [cdt-dev] [DSF] SessionType

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> Sent: Thursday, July 08, 2010 12:28 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] [DSF] SessionType
> 
> Is it me or are we really running into problems with DSF-GDB 
> extensibility and customizability? Do we need to take a step back and 
> document all the use cases we're trying to accomplish with gdb in the 
> many different environments it supports and tweak the architecture to 
> make sure we can do them all easily?

During the development of DSF-GDB, DSF itself was modified as we learned
what was needed for a good integration.  The problems that arise now are
specific to DSF-GDB, because we never had to deal with specializing
DSF-GDB itself.  

With the 'services' approach given by DSF, almost all aspects of DSF-GDB
can easily be changed.  But that requires replacing a DSF-GDB service
with a custom service.  Understandably, people instead want to re-use as
much of DSF-GDB as possible while still customizing it.
Although we don't want to push this re-use too far (at some point it's
normal that since it is not DSF-GDB, it just doesn't use some DSF-GDB
code), I think we can do some work to make DSF-GDB something that is
better built to be extended.

Doug is right that it would be good to take a step back and figure out
which cases should be improved and how to improve them in a sound
manner.

I've created (yet another) wiki to allow people to express their needs
for DSF-GDB extensibility.
http://wiki.eclipse.org/CDT/cdt-debug-dsf-gdb-extensibility
It is under the main wiki->Component Documentation-> DSF-GDB
extensibility 

Marc