Home » Archived » DSDP » call for participation in Target Management
| call for participation in Target Management [message #310] |
Thu, 26 May 2005 16:20  |
Eclipse User |
|
|
|
Originally posted by: Rudolf.Frauenschuh.gmx.net
This is an invitation to anyone interested in the upcoming Target
Management subproject.
Please post to this newsgroup entry:
- who you are (including organzation)
- what do you expect technically from Target Management (if it's more than
listed here)
- what kind of participation you want (being informed, participate in
discussions, do actual work, ...)
- and anything you want to say regarding the proposed Target Management
subproject
Prior discussions with many companies made it clear that there is a lot of
interest in this topic. And a lot of common requirements. Please post here
to make this fact also visible to other organizations and the Eclipse board
which measures the interest in DSDP and it's subprojects also in terms of
newsgroup postings. That's vital for the adoption of the proposed DSDP top
level project and it's subprojects like Target Management.
As a first step of real work and to foster discussion WindRiver will come up
with a list of use cases we see for Target Management (planned for early
June).
To give you an idea of what we see as the scope of the Target Management
subproject I repeat here the part of the DSDP project proposal dealing with
Target Management.
>>>>>>>>>>>
Target Management
A lot of software is developed that needs to be run on a remote system.
Developers have to connect to these systems to download software and data,
start and stop programs, debug programs and more. The goal of the Target
Management project is to provide data models and frameworks to manage remote
systems, their connections and their services. Although Target Management is
a fundamental requirement in the embedded world, it could also be used in
the Enterprise for remote development to manage connections between clients
and servers to build and debug applications remotely.
There are many different processors, boards, operating systems, connection
protocols (e.g. TCP/IP, serial, JTAG, proprietary) and services (console,
query, run control, ping, download, events, debug) used. Often many of these
interfaces are present at the same time, so developers need to manage the
different devices and their configurations. The Target Management project
will provide plug-ins to simplify configuration and management of a wide
range of connection mechanisms.
A first attempt for a "Remote System (Target) Definition" has been made in
the CDT. The proposal discusses a framework that provides an abstraction of
connections and services on a remote target. Such an abstraction will allow
for the creation of tools that unify the access to remote targets and
simplify the creation of launch configurations. For details, see Bugzilla
entry: Bug 65471
We propose to extend this work in the following steps:
a.. Extensions and additional data models for connection protocols,
services, devices and whatever needs to be abstracted
b.. Frameworks to enable interaction with remote devices like: connect,
query, download, start, stop, debug, etc.
c.. Abstractions and a framework for functionality needed to launch
programs including sequencing, parameter passing, conditions, timing, etc.
d.. Capabilities to manage numerous shared devices over the network
The target manager plugin created in this project will provide
general-purpose capabilities to manage connection configurations, monitor
status, transfer data, and launch and debug programs on remote devices based
on gdb. Vendors can extend the target manager with connection mechanisms
specific to their environment and operating system.
|
|
|
| Re: call for participation in Target Management [message #317 is a reply to message #310] |
Thu, 26 May 2005 21:29  |
| Eclipse User |
|
|
|
Originally posted by: aaron_spear.mycompanyname.com
Hello All,
My name is Aaron Spear and I am the debugger architect for Accelerated
Technology (aka Mentor Graphics Embedded Systems Division).
-What we expect:
We currently have a multi-core/process/thread debugger for embedded systems
based on Eclipse that we are currently shipping (the product is called
"Nucleus EDGE"). Our debugger is a ground up implementation of the Eclipse
debug model specialized for embedded systems. (currently we don't use the
CDT). We are betting the ranch on a family of Eclipse based products and as
such are very interested in connectivity to embedded systems, and of course
how we can fit well with the rest of the Eclipse ecosystem. Like others
that offer an embedded debugger based on Eclipse, we have invented our own
mechanisms to catalog and connect to arbitrary embedded systems. Our
architecture builds on top of the Eclipse launching framework, walking the
user through wizards to select what sort of connection mechanism they want
to use for their target. For simple connections (e.g. "bare metal" core(s)
with a third party JTAG box) this works sufficiently well. However, when
you start talking about attaching to processes running on remote machines,
this mechanism becomes somewhat cumbersome. So, we also recognize the need
for a common refined framework for connectivity. Otherwise we will all
spend our time writing what amounts to a commodity...
-What kind of participation you want:
Certainly we would like to be involved with developing the specification of
the framework, and could contribute some engineering bandwidth to
implementation as well. In conversations that I have had with Wind folks
and others at the Chicago meeting last month, it seems clear that the shared
target management framework is one thing, but then debugger vendors like
ourselves will provide the implementation of some interfaces for their
particular connection methodologies. So, certainly we would be doing the
implementation of this for our debug environment, and then collaborating
with everyone else on issues with the platform.
Our needs from target management:
We have a number of different use cases we need to support. Nothing new
here really, they are similar to everyone else's needs (since in some cases
we are competitors, which I still think is weird, but I am getting over it
;-)
1) We have a prototyping product that can be used to develop code for the
target on the host (not ISS based...) and so we need to actually launch and
debug executables on the host (attach as well). We are not typically trying
to sell it as a native debugger, but it works well for that too...
2) The majority of our customers work at a pretty low level, close to the
hw. They use third party JTAG probes and work with fast lightweight RTOS'es
or no OS at all. JTAG probes may be network based or attached to the
workstation somehow (serial/parallel/USB)
3) Connecting to ISS based systems to emulate physical hardware
4) connections to remote OSes: connect to a debug agent, get a list of
current processes, attach to one and debug it, download a new one, profile a
process, etc
We model all of these the same way right now. In general you select your
target type, then connection type, then a connection method, and then
parameters that are specific to that combination. These are saved in a
launch. As I said before this works fine for connecting to something that
is static (e.g. the board on your desk connected to a JTAG probe), but when
it comes to dynamic things, like attaching to a process on an arbitrary
machine, we have to invent other ways of having the user select what they
want to connect to (pop up a dialog with a list of available processes)
This could definitely use some normalization so that other tools can build
on top of debuggers in a more or less portable way.
regards,
Aaron
"exquisitus" <Rudolf.Frauenschuh@gmx.net> wrote in message
news:d74t7n$abp$1@news.eclipse.org...
> This is an invitation to anyone interested in the upcoming Target
> Management subproject.
>
> Please post to this newsgroup entry:
> - who you are (including organzation)
> - what do you expect technically from Target Management (if it's more than
> listed here)
> - what kind of participation you want (being informed, participate in
> discussions, do actual work, ...)
> - and anything you want to say regarding the proposed Target Management
> subproject
>
> Prior discussions with many companies made it clear that there is a lot of
> interest in this topic. And a lot of common requirements. Please post here
> to make this fact also visible to other organizations and the Eclipse
board
> which measures the interest in DSDP and it's subprojects also in terms of
> newsgroup postings. That's vital for the adoption of the proposed DSDP top
> level project and it's subprojects like Target Management.
>
> As a first step of real work and to foster discussion WindRiver will come
up
> with a list of use cases we see for Target Management (planned for early
> June).
>
> To give you an idea of what we see as the scope of the Target Management
> subproject I repeat here the part of the DSDP project proposal dealing
with
> Target Management.
>
> >>>>>>>>>>>
> Target Management
> A lot of software is developed that needs to be run on a remote system.
> Developers have to connect to these systems to download software and data,
> start and stop programs, debug programs and more. The goal of the Target
> Management project is to provide data models and frameworks to manage
remote
> systems, their connections and their services. Although Target Management
is
> a fundamental requirement in the embedded world, it could also be used in
> the Enterprise for remote development to manage connections between
clients
> and servers to build and debug applications remotely.
>
> There are many different processors, boards, operating systems, connection
> protocols (e.g. TCP/IP, serial, JTAG, proprietary) and services (console,
> query, run control, ping, download, events, debug) used. Often many of
these
> interfaces are present at the same time, so developers need to manage the
> different devices and their configurations. The Target Management project
> will provide plug-ins to simplify configuration and management of a wide
> range of connection mechanisms.
>
> A first attempt for a "Remote System (Target) Definition" has been made in
> the CDT. The proposal discusses a framework that provides an abstraction
of
> connections and services on a remote target. Such an abstraction will
allow
> for the creation of tools that unify the access to remote targets and
> simplify the creation of launch configurations. For details, see Bugzilla
> entry: Bug 65471
>
> We propose to extend this work in the following steps:
>
> a.. Extensions and additional data models for connection protocols,
> services, devices and whatever needs to be abstracted
> b.. Frameworks to enable interaction with remote devices like: connect,
> query, download, start, stop, debug, etc.
> c.. Abstractions and a framework for functionality needed to launch
> programs including sequencing, parameter passing, conditions, timing, etc.
> d.. Capabilities to manage numerous shared devices over the network
> The target manager plugin created in this project will provide
> general-purpose capabilities to manage connection configurations, monitor
> status, transfer data, and launch and debug programs on remote devices
based
> on gdb. Vendors can extend the target manager with connection mechanisms
> specific to their environment and operating system.
>
|
|
|
| Re: call for participation in Target Management [message #322 is a reply to message #310] |
Tue, 31 May 2005 13:52 |
| Eclipse User |
|
|
|
Originally posted by: crecoskie.ti.com
This may be redundant for some people on the list whom we've already been
talking to about DSDP, so if you are one of them, excuse the redundancy :-)
My name is Chris Recoskie and I'm with Texas Instruments. TI has a team
of developers working on our Eclipse-based Code Composer Essentials
product line, and we are all very interested in DSDP. You will likely see
myself, Andy Waterson, Martin Imrisek, Dobrin Alexiev, and others on our
team popping up from time to time.
TI is interested in full participation in the project as a whole and also
this subproject specifically. It's too early to comment on the specifics
of how many resources we will be able to commit or to what exactly they
would be allocated to, but we expect to be chipping in with some of the
work on DSDP in additon to participating in discussions.
In terms of the target management subproject, our desires essentially
mirror the proposal. Our primary focus is for setup and debugging of
embedded processors on JTAG scan chains, so we hope to see a sufficient
level of abstraction in the target management model to facilitate this.
We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
is likely in the future that we will want to have non-GDB based debuggers
as well.
On behalf of everyone on our team, I would just like to close in saying
that we are looking forward to our future discussions and to our
participation in DSDP.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
|
|
|
| Re: call for participation in Target Management [message #324 is a reply to message #322] |
Tue, 31 May 2005 15:29 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
>We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
>is likely in the future that we will want to have non-GDB based debuggers
>as well.
To be more accurate, the gdb-based debugger is the default implementation of
the CDT API. There are non-gdb debuggers based on the CDT. There is a
subproject based on the Windows API calls and there are implementations
based on the CDI interface (unfortunately not open source).
The CDT debugger is not restricted to gdb. It provides the gdb-based
debugger implementation as an example on how to use the interfaces
"Chris Recoskie" <crecoskie@ti.com> wrote in message
news:1af1c6da330554ddfabc9e85f30fd373$1@www.eclipse.org...
> This may be redundant for some people on the list whom we've already been
> talking to about DSDP, so if you are one of them, excuse the redundancy
> :-)
>
> My name is Chris Recoskie and I'm with Texas Instruments. TI has a team
> of developers working on our Eclipse-based Code Composer Essentials
> product line, and we are all very interested in DSDP. You will likely see
> myself, Andy Waterson, Martin Imrisek, Dobrin Alexiev, and others on our
> team popping up from time to time.
>
> TI is interested in full participation in the project as a whole and also
> this subproject specifically. It's too early to comment on the specifics
> of how many resources we will be able to commit or to what exactly they
> would be allocated to, but we expect to be chipping in with some of the
> work on DSDP in additon to participating in discussions.
>
> In terms of the target management subproject, our desires essentially
> mirror the proposal. Our primary focus is for setup and debugging of
> embedded processors on JTAG scan chains, so we hope to see a sufficient
> level of abstraction in the target management model to facilitate this.
> We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
> is likely in the future that we will want to have non-GDB based debuggers
> as well.
>
> On behalf of everyone on our team, I would just like to close in saying
> that we are looking forward to our future discussions and to our
> participation in DSDP.
>
>
> ___________________________________________
>
>
> Chris Recoskie
>
>
> Software Designer
> IDE Frameworks Group
> Texas Instruments, Toronto
>
>
>
|
|
|
| Re: call for participation in Target Management [message #565862 is a reply to message #310] |
Thu, 26 May 2005 21:29 |
| Eclipse User |
|
|
|
Originally posted by: aaron_spear.mycompanyname.com
Hello All,
My name is Aaron Spear and I am the debugger architect for Accelerated
Technology (aka Mentor Graphics Embedded Systems Division).
-What we expect:
We currently have a multi-core/process/thread debugger for embedded systems
based on Eclipse that we are currently shipping (the product is called
"Nucleus EDGE"). Our debugger is a ground up implementation of the Eclipse
debug model specialized for embedded systems. (currently we don't use the
CDT). We are betting the ranch on a family of Eclipse based products and as
such are very interested in connectivity to embedded systems, and of course
how we can fit well with the rest of the Eclipse ecosystem. Like others
that offer an embedded debugger based on Eclipse, we have invented our own
mechanisms to catalog and connect to arbitrary embedded systems. Our
architecture builds on top of the Eclipse launching framework, walking the
user through wizards to select what sort of connection mechanism they want
to use for their target. For simple connections (e.g. "bare metal" core(s)
with a third party JTAG box) this works sufficiently well. However, when
you start talking about attaching to processes running on remote machines,
this mechanism becomes somewhat cumbersome. So, we also recognize the need
for a common refined framework for connectivity. Otherwise we will all
spend our time writing what amounts to a commodity...
-What kind of participation you want:
Certainly we would like to be involved with developing the specification of
the framework, and could contribute some engineering bandwidth to
implementation as well. In conversations that I have had with Wind folks
and others at the Chicago meeting last month, it seems clear that the shared
target management framework is one thing, but then debugger vendors like
ourselves will provide the implementation of some interfaces for their
particular connection methodologies. So, certainly we would be doing the
implementation of this for our debug environment, and then collaborating
with everyone else on issues with the platform.
Our needs from target management:
We have a number of different use cases we need to support. Nothing new
here really, they are similar to everyone else's needs (since in some cases
we are competitors, which I still think is weird, but I am getting over it
;-)
1) We have a prototyping product that can be used to develop code for the
target on the host (not ISS based...) and so we need to actually launch and
debug executables on the host (attach as well). We are not typically trying
to sell it as a native debugger, but it works well for that too...
2) The majority of our customers work at a pretty low level, close to the
hw. They use third party JTAG probes and work with fast lightweight RTOS'es
or no OS at all. JTAG probes may be network based or attached to the
workstation somehow (serial/parallel/USB)
3) Connecting to ISS based systems to emulate physical hardware
4) connections to remote OSes: connect to a debug agent, get a list of
current processes, attach to one and debug it, download a new one, profile a
process, etc
We model all of these the same way right now. In general you select your
target type, then connection type, then a connection method, and then
parameters that are specific to that combination. These are saved in a
launch. As I said before this works fine for connecting to something that
is static (e.g. the board on your desk connected to a JTAG probe), but when
it comes to dynamic things, like attaching to a process on an arbitrary
machine, we have to invent other ways of having the user select what they
want to connect to (pop up a dialog with a list of available processes)
This could definitely use some normalization so that other tools can build
on top of debuggers in a more or less portable way.
regards,
Aaron
"exquisitus" <Rudolf.Frauenschuh@gmx.net> wrote in message
news:d74t7n$abp$1@news.eclipse.org...
> This is an invitation to anyone interested in the upcoming Target
> Management subproject.
>
> Please post to this newsgroup entry:
> - who you are (including organzation)
> - what do you expect technically from Target Management (if it's more than
> listed here)
> - what kind of participation you want (being informed, participate in
> discussions, do actual work, ...)
> - and anything you want to say regarding the proposed Target Management
> subproject
>
> Prior discussions with many companies made it clear that there is a lot of
> interest in this topic. And a lot of common requirements. Please post here
> to make this fact also visible to other organizations and the Eclipse
board
> which measures the interest in DSDP and it's subprojects also in terms of
> newsgroup postings. That's vital for the adoption of the proposed DSDP top
> level project and it's subprojects like Target Management.
>
> As a first step of real work and to foster discussion WindRiver will come
up
> with a list of use cases we see for Target Management (planned for early
> June).
>
> To give you an idea of what we see as the scope of the Target Management
> subproject I repeat here the part of the DSDP project proposal dealing
with
> Target Management.
>
> >>>>>>>>>>>
> Target Management
> A lot of software is developed that needs to be run on a remote system.
> Developers have to connect to these systems to download software and data,
> start and stop programs, debug programs and more. The goal of the Target
> Management project is to provide data models and frameworks to manage
remote
> systems, their connections and their services. Although Target Management
is
> a fundamental requirement in the embedded world, it could also be used in
> the Enterprise for remote development to manage connections between
clients
> and servers to build and debug applications remotely.
>
> There are many different processors, boards, operating systems, connection
> protocols (e.g. TCP/IP, serial, JTAG, proprietary) and services (console,
> query, run control, ping, download, events, debug) used. Often many of
these
> interfaces are present at the same time, so developers need to manage the
> different devices and their configurations. The Target Management project
> will provide plug-ins to simplify configuration and management of a wide
> range of connection mechanisms.
>
> A first attempt for a "Remote System (Target) Definition" has been made in
> the CDT. The proposal discusses a framework that provides an abstraction
of
> connections and services on a remote target. Such an abstraction will
allow
> for the creation of tools that unify the access to remote targets and
> simplify the creation of launch configurations. For details, see Bugzilla
> entry: Bug 65471
>
> We propose to extend this work in the following steps:
>
> a.. Extensions and additional data models for connection protocols,
> services, devices and whatever needs to be abstracted
> b.. Frameworks to enable interaction with remote devices like: connect,
> query, download, start, stop, debug, etc.
> c.. Abstractions and a framework for functionality needed to launch
> programs including sequencing, parameter passing, conditions, timing, etc.
> d.. Capabilities to manage numerous shared devices over the network
> The target manager plugin created in this project will provide
> general-purpose capabilities to manage connection configurations, monitor
> status, transfer data, and launch and debug programs on remote devices
based
> on gdb. Vendors can extend the target manager with connection mechanisms
> specific to their environment and operating system.
>
|
|
|
| Re: call for participation in Target Management [message #565923 is a reply to message #310] |
Tue, 31 May 2005 13:52 |
 Chris Recoskie
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
This may be redundant for some people on the list whom we've already been
talking to about DSDP, so if you are one of them, excuse the redundancy :-)
My name is Chris Recoskie and I'm with Texas Instruments. TI has a team
of developers working on our Eclipse-based Code Composer Essentials
product line, and we are all very interested in DSDP. You will likely see
myself, Andy Waterson, Martin Imrisek, Dobrin Alexiev, and others on our
team popping up from time to time.
TI is interested in full participation in the project as a whole and also
this subproject specifically. It's too early to comment on the specifics
of how many resources we will be able to commit or to what exactly they
would be allocated to, but we expect to be chipping in with some of the
work on DSDP in additon to participating in discussions.
In terms of the target management subproject, our desires essentially
mirror the proposal. Our primary focus is for setup and debugging of
embedded processors on JTAG scan chains, so we hope to see a sufficient
level of abstraction in the target management model to facilitate this.
We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
is likely in the future that we will want to have non-GDB based debuggers
as well.
On behalf of everyone on our team, I would just like to close in saying
that we are looking forward to our future discussions and to our
participation in DSDP.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
|
|
|
| Re: call for participation in Target Management [message #565949 is a reply to message #322] |
Tue, 31 May 2005 15:29 |
| Eclipse User |
|
|
|
>We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
>is likely in the future that we will want to have non-GDB based debuggers
>as well.
To be more accurate, the gdb-based debugger is the default implementation of
the CDT API. There are non-gdb debuggers based on the CDT. There is a
subproject based on the Windows API calls and there are implementations
based on the CDI interface (unfortunately not open source).
The CDT debugger is not restricted to gdb. It provides the gdb-based
debugger implementation as an example on how to use the interfaces
"Chris Recoskie" <crecoskie@ti.com> wrote in message
news:1af1c6da330554ddfabc9e85f30fd373$1@www.eclipse.org...
> This may be redundant for some people on the list whom we've already been
> talking to about DSDP, so if you are one of them, excuse the redundancy
> :-)
>
> My name is Chris Recoskie and I'm with Texas Instruments. TI has a team
> of developers working on our Eclipse-based Code Composer Essentials
> product line, and we are all very interested in DSDP. You will likely see
> myself, Andy Waterson, Martin Imrisek, Dobrin Alexiev, and others on our
> team popping up from time to time.
>
> TI is interested in full participation in the project as a whole and also
> this subproject specifically. It's too early to comment on the specifics
> of how many resources we will be able to commit or to what exactly they
> would be allocated to, but we expect to be chipping in with some of the
> work on DSDP in additon to participating in discussions.
>
> In terms of the target management subproject, our desires essentially
> mirror the proposal. Our primary focus is for setup and debugging of
> embedded processors on JTAG scan chains, so we hope to see a sufficient
> level of abstraction in the target management model to facilitate this.
> We have current Eclipse + CDT products (i.e. CCE) which utilize GDB but it
> is likely in the future that we will want to have non-GDB based debuggers
> as well.
>
> On behalf of everyone on our team, I would just like to close in saying
> that we are looking forward to our future discussions and to our
> participation in DSDP.
>
>
> ___________________________________________
>
>
> Chris Recoskie
>
>
> Software Designer
> IDE Frameworks Group
> Texas Instruments, Toronto
>
>
>
|
|
|
Goto Forum:
Current Time: Thu Nov 14 10:07:09 GMT 2024
Powered by FUDForum. Page generated in 0.03528 seconds |
] 
Search
Help
Register
Login
Home
