Home » Archived » DSDP » Use Cases for Target Management
|
| Re: Use Cases for Target Management [message #495 is a reply to message #478] |
Tue, 07 June 2005 19:24   |
Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
>The scope of Target Management ends where registered tools like a debugger
>or test
>automation framework take over.
Is it assumed that the access to the register-related information and memory
management is not a part of the target definition and should be provided by
special services like debug agents?
Thanks,
Mikhail Khodjaiants
QNX Software Systems
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d81s4m$29q$1@news.eclipse.org...
> As Rudolf Frauenschuh has announced two weeks ago, we have compiled a list
> of Use Cases for Target Management. Attached document outlines how we see
> Target Management at Wind River.
> We are distributing this document in order to
>
> - Ensure that interested parties have the same understanding what Target
> Management is, what it can do and what it cannot (or will not) do.
> - Create a common terminology for Target Management.
> - Make sure that we keep all known desired uses of Target Management in
> mind when designing the basic framework.
>
> We invite all interested parties to review and comment on the document.
> We'd
> especially like to know if you see anything differently, or you feel that
> any use cases are missing. Please also let us know if you find some better
> terminology for concepts stated, or you'd propose to highlight some other
> concepts.
>
> The goal of this document is to convey the Big Picture of target
> management,
> to ensure that the frameworks we are going to discuss are versatile enough
> even though not all use cases may be implemented any time soon.
>
> We are looking forward to lots of feedback
>
> Thanks,
> Martin
>
> --
> DI Martin Oberhuber
> Member of Technical Staff
> WindRiver, Salzburg, Austria
>
>
>
|
|
|
| Re: Use Cases for Target Management [message #507 is a reply to message #495] |
Thu, 09 June 2005 10:14 |
 Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello Mikhail,
could you clarify a bit more, what you mean by register-related information
and
memory management? What use cases / scenarios do you have in mind?
My first feeling is that accessing CPU registers, which makes sense only
when
the CPU is stopped, would be done by a debugger. Similarly, displaying and
modifying memory regions in a hex editor would also be done by a debugger.
The debugger could, however, use the target definition as a generic data
store
to save target-related setup information.
When you think about JTAG register sets in a hardware emulator, in a sense
that the
emulator needs to load the register definition file before it can connect to
a board, I would
think that the required register definition could be stored with the target
connection
data since it describes the physical structure of the target. The actual
action of loading
the register def into the emulator could be done by a target manager
connection type plugin.
I think it depends a little on how your hardware debugging solution is
structured;
when the hardware box (and the register def) can only be used within the
debugger,
loading the register set could as well be done in the debugger. When the
hardware
box can provide other services "outside a debugging session" as well, it
would make
sense to do this in the target manager.
For memory management, please clarify more.
Thanks,
Martin
"Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
news:d84s9l$pt8$1@news.eclipse.org...
> >The scope of Target Management ends where registered tools like a
debugger
> >or test
> >automation framework take over.
>
> Is it assumed that the access to the register-related information and
memory
> management is not a part of the target definition and should be provided
by
> special services like debug agents?
>
> Thanks,
> Mikhail Khodjaiants
> QNX Software Systems
|
|
|
| Re: Use Cases for Target Management [message #517 is a reply to message #507] |
Thu, 09 June 2005 15:26 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
Hi Martin,
Thanks for your answer. Sorry, I wasn't clear, the memory management is a
bad example.
The first question is very simple and is about the definitions of CPU
registers, not the access. This information is static. Traditionally the
debug agents are responsible to provide it, which means a running debug
session is needed to get the CPU's registers groups, register names and
types. I would rather expect to have special target services defined for
this and similar purposes as a part of Target Inventory instead of pushing
it to the debug agents.
Thanks,
Mikhail
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d894qj$iho$1@news.eclipse.org...
> Hello Mikhail,
>
> could you clarify a bit more, what you mean by register-related
> information
> and
> memory management? What use cases / scenarios do you have in mind?
>
> My first feeling is that accessing CPU registers, which makes sense only
> when
> the CPU is stopped, would be done by a debugger. Similarly, displaying and
> modifying memory regions in a hex editor would also be done by a debugger.
> The debugger could, however, use the target definition as a generic data
> store
> to save target-related setup information.
>
> When you think about JTAG register sets in a hardware emulator, in a sense
> that the
> emulator needs to load the register definition file before it can connect
> to
> a board, I would
> think that the required register definition could be stored with the
> target
> connection
> data since it describes the physical structure of the target. The actual
> action of loading
> the register def into the emulator could be done by a target manager
> connection type plugin.
>
> I think it depends a little on how your hardware debugging solution is
> structured;
> when the hardware box (and the register def) can only be used within the
> debugger,
> loading the register set could as well be done in the debugger. When the
> hardware
> box can provide other services "outside a debugging session" as well, it
> would make
> sense to do this in the target manager.
>
> For memory management, please clarify more.
>
> Thanks,
> Martin
>
> "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> news:d84s9l$pt8$1@news.eclipse.org...
>> >The scope of Target Management ends where registered tools like a
> debugger
>> >or test
>> >automation framework take over.
>>
>> Is it assumed that the access to the register-related information and
> memory
>> management is not a part of the target definition and should be provided
> by
>> special services like debug agents?
>>
>> Thanks,
>> Mikhail Khodjaiants
>> QNX Software Systems
>
>
|
|
|
| Re: Use Cases for Target Management [message #544 is a reply to message #517] |
Thu, 09 June 2005 16:20 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello Mikhail,
my first impression was that the register groups, register names and types
were
sufficiently described by knowing the exact CPU variant (as a String). The
CPU
variant would be stored with the target definition and could be retrieved by
target
inventory. A debugger would "know" correct register setup based on the the
CPU
variant.
But if you feel that the full register definition should be stored with the
target definition,
the data structures we define should be versatile enough to allow storing it
as opaque
data which is accessed by custom inventory and debug plugins.
It would be up to plug-in writers to contribute the target inventory
service, property
pages for manual editing (if desired), and debug service for using it. The
framework
we are designing would treat the register definitions as opaque data since I
believe
they would not be used anywhere except the debugger.
Would that fit your needs?
Cheers,
Martin
"Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
news:d89n3u$c4k$1@news.eclipse.org...
> Hi Martin,
>
> Thanks for your answer. Sorry, I wasn't clear, the memory management is a
> bad example.
> The first question is very simple and is about the definitions of CPU
> registers, not the access. This information is static. Traditionally the
> debug agents are responsible to provide it, which means a running debug
> session is needed to get the CPU's registers groups, register names and
> types. I would rather expect to have special target services defined for
> this and similar purposes as a part of Target Inventory instead of pushing
> it to the debug agents.
>
> Thanks,
> Mikhail
>
> "Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
> news:d894qj$iho$1@news.eclipse.org...
> > Hello Mikhail,
> >
> > could you clarify a bit more, what you mean by register-related
> > information
> > and
> > memory management? What use cases / scenarios do you have in mind?
> >
> > My first feeling is that accessing CPU registers, which makes sense only
> > when
> > the CPU is stopped, would be done by a debugger. Similarly, displaying
and
> > modifying memory regions in a hex editor would also be done by a
debugger.
> > The debugger could, however, use the target definition as a generic data
> > store
> > to save target-related setup information.
> >
> > When you think about JTAG register sets in a hardware emulator, in a
sense
> > that the
> > emulator needs to load the register definition file before it can
connect
> > to
> > a board, I would
> > think that the required register definition could be stored with the
> > target
> > connection
> > data since it describes the physical structure of the target. The actual
> > action of loading
> > the register def into the emulator could be done by a target manager
> > connection type plugin.
> >
> > I think it depends a little on how your hardware debugging solution is
> > structured;
> > when the hardware box (and the register def) can only be used within the
> > debugger,
> > loading the register set could as well be done in the debugger. When the
> > hardware
> > box can provide other services "outside a debugging session" as well, it
> > would make
> > sense to do this in the target manager.
> >
> > For memory management, please clarify more.
> >
> > Thanks,
> > Martin
> >
> > "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> > news:d84s9l$pt8$1@news.eclipse.org...
> >> >The scope of Target Management ends where registered tools like a
> > debugger
> >> >or test
> >> >automation framework take over.
> >>
> >> Is it assumed that the access to the register-related information and
> > memory
> >> management is not a part of the target definition and should be
provided
> > by
> >> special services like debug agents?
> >>
> >> Thanks,
> >> Mikhail Khodjaiants
> >> QNX Software Systems
> >
> >
>
>
|
|
|
| Re: Use Cases for Target Management [message #558 is a reply to message #544] |
Thu, 09 June 2005 18:50 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
As an example I'll describe the situation I am dealing with in the CDT
debugger. The requirement is to add support for user-defined register
groups, i.e. the user selects registers that he/she wants to watch during
the debugging session. This has to be done before launching. The natural way
is to retrieve the list of all CPU registers from the target and make a
selection.
Correct me if I'm wrong, but in your scenario the CDT debugger should keep
the list of CPU variants with the corresponding register defintions. My
suggestion is to make the target responsible for providing this information.
This could be iimplemented as a data store inside the target management
plugins or somehow else, but an API is needed to provide access to this
information.
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d89q7n$gjl$1@news.eclipse.org...
> Hello Mikhail,
>
> my first impression was that the register groups, register names and types
> were
> sufficiently described by knowing the exact CPU variant (as a String). The
> CPU
> variant would be stored with the target definition and could be retrieved
> by
> target
> inventory. A debugger would "know" correct register setup based on the the
> CPU
> variant.
>
> But if you feel that the full register definition should be stored with
> the
> target definition,
> the data structures we define should be versatile enough to allow storing
> it
> as opaque
> data which is accessed by custom inventory and debug plugins.
>
> It would be up to plug-in writers to contribute the target inventory
> service, property
> pages for manual editing (if desired), and debug service for using it. The
> framework
> we are designing would treat the register definitions as opaque data since
> I
> believe
> they would not be used anywhere except the debugger.
>
> Would that fit your needs?
>
> Cheers,
> Martin
>
>
> "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> news:d89n3u$c4k$1@news.eclipse.org...
>> Hi Martin,
>>
>> Thanks for your answer. Sorry, I wasn't clear, the memory management is a
>> bad example.
>> The first question is very simple and is about the definitions of CPU
>> registers, not the access. This information is static. Traditionally the
>> debug agents are responsible to provide it, which means a running debug
>> session is needed to get the CPU's registers groups, register names and
>> types. I would rather expect to have special target services defined for
>> this and similar purposes as a part of Target Inventory instead of
>> pushing
>> it to the debug agents.
>>
>> Thanks,
>> Mikhail
>>
>> "Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
>> news:d894qj$iho$1@news.eclipse.org...
>> > Hello Mikhail,
>> >
>> > could you clarify a bit more, what you mean by register-related
>> > information
>> > and
>> > memory management? What use cases / scenarios do you have in mind?
>> >
>> > My first feeling is that accessing CPU registers, which makes sense
>> > only
>> > when
>> > the CPU is stopped, would be done by a debugger. Similarly, displaying
> and
>> > modifying memory regions in a hex editor would also be done by a
> debugger.
>> > The debugger could, however, use the target definition as a generic
>> > data
>> > store
>> > to save target-related setup information.
>> >
>> > When you think about JTAG register sets in a hardware emulator, in a
> sense
>> > that the
>> > emulator needs to load the register definition file before it can
> connect
>> > to
>> > a board, I would
>> > think that the required register definition could be stored with the
>> > target
>> > connection
>> > data since it describes the physical structure of the target. The
>> > actual
>> > action of loading
>> > the register def into the emulator could be done by a target manager
>> > connection type plugin.
>> >
>> > I think it depends a little on how your hardware debugging solution is
>> > structured;
>> > when the hardware box (and the register def) can only be used within
>> > the
>> > debugger,
>> > loading the register set could as well be done in the debugger. When
>> > the
>> > hardware
>> > box can provide other services "outside a debugging session" as well,
>> > it
>> > would make
>> > sense to do this in the target manager.
>> >
>> > For memory management, please clarify more.
>> >
>> > Thanks,
>> > Martin
>> >
>> > "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
>> > news:d84s9l$pt8$1@news.eclipse.org...
>> >> >The scope of Target Management ends where registered tools like a
>> > debugger
>> >> >or test
>> >> >automation framework take over.
>> >>
>> >> Is it assumed that the access to the register-related information and
>> > memory
>> >> management is not a part of the target definition and should be
> provided
>> > by
>> >> special services like debug agents?
>> >>
>> >> Thanks,
>> >> Mikhail Khodjaiants
>> >> QNX Software Systems
>> >
>> >
>>
>>
>
>
|
|
|
| Re: Use Cases for Target Management [message #570 is a reply to message #478] |
Fri, 10 June 2005 13:31 |
David Dykstal
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
At EclipseCon, IBM presented a poster describing an eclipse-based
Remote Systems Explorer that seems to meet several of the goals that
are specified in this paper. The component is used in several IBM
products, has been shipping for several years, and is available to our
business partners. It comes from a different background than these
proposals, but there is much in common, particularly since there seems
to be a goal of expanding target management support beyond the DSDP
space.
The underlying framework is pluggable and allows multiple services to
be made available from targets based on system type. A developer is
therefore be able to work on several types of systems or devices at a
time and not be constrained to a common set of services.
RSE's demands on target systems can be quite small.
We have a presentation (admittedly UI heavy) on our site that
describes this.
http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
We've long considered making this component available. Would this be
interesting to this project at all?
-- David Dykstal, IBM
On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
<martin.oberhuber@windriver.com> wrote:
>As Rudolf Frauenschuh has announced two weeks ago, we have compiled a list
>of Use Cases for Target Management. Attached document outlines how we see
>Target Management at Wind River.
>We are distributing this document in order to
>
> - Ensure that interested parties have the same understanding what Target
>Management is, what it can do and what it cannot (or will not) do.
> - Create a common terminology for Target Management.
> - Make sure that we keep all known desired uses of Target Management in
>mind when designing the basic framework.
>
>We invite all interested parties to review and comment on the document. We'd
>especially like to know if you see anything differently, or you feel that
>any use cases are missing. Please also let us know if you find some better
>terminology for concepts stated, or you'd propose to highlight some other
>concepts.
>
>The goal of this document is to convey the Big Picture of target management,
>to ensure that the frameworks we are going to discuss are versatile enough
>even though not all use cases may be implemented any time soon.
>
>We are looking forward to lots of feedback
>
>Thanks,
>Martin
|
|
|
| Re: Use Cases for Target Management [message #594 is a reply to message #570] |
Fri, 10 June 2005 15:01 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello David,
thanks a lot for your posting. I've had a look at the presentation you
mentioned, and I'm sure that RSE would most definitely be interesting for
the Target Management Project!
* RSE server could be a service plugged in to Target Managent for upload,
download and remote command
* RSE views could support Target Management upload, download and remote
command use cases (when you said "pluggable", I understand that
communication protocols managed by TM could be used by RSE)
* RSE's profiles and team-sharing concepts seem to be very interesting, we'd
need to get more insight to understand these better
* RSE's re-usable parts for integral Eclipse dialogs seem to be very
powerful
While RSE currently seems to be centered on file transfer and remote
command, the Target Management project could extend RSE by
* supporting standard-based connections like FTP, rsh, ssh such that no
agent is needed on the remote system
* supporting OS-less "bare metal" hardware debuggers as connection types
* retrieving information about OS objects like processes, threads (to allow
debugger attachment), and potentially information about other resources
* integrating with Launch Configurations to facilitate program run and debug
on remote systems.
* integrating with target registries to support discovery and reservation of
remote systems
It appears that there is an excellent match for collaboration.
How can we proceed? Would you like to join the TM conference call on monday?
Thanks,
Martin Oberhuber, Wind River Systems
"David Dykstal" <david_dykstal@us.ibm.com> wrote in message
news:u94ja156anj75r5vdprrob2hsldtm3h9du@4ax.com...
> At EclipseCon, IBM presented a poster describing an eclipse-based
> Remote Systems Explorer that seems to meet several of the goals that
> are specified in this paper. The component is used in several IBM
> products, has been shipping for several years, and is available to our
> business partners. It comes from a different background than these
> proposals, but there is much in common, particularly since there seems
> to be a goal of expanding target management support beyond the DSDP
> space.
>
> The underlying framework is pluggable and allows multiple services to
> be made available from targets based on system type. A developer is
> therefore be able to work on several types of systems or devices at a
> time and not be constrained to a common set of services.
>
> RSE's demands on target systems can be quite small.
>
> We have a presentation (admittedly UI heavy) on our site that
> describes this.
>
> http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
>
> We've long considered making this component available. Would this be
> interesting to this project at all?
>
> -- David Dykstal, IBM
>
> On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
> <martin.oberhuber@windriver.com> wrote:
>
> >As Rudolf Frauenschuh has announced two weeks ago, we have compiled a
list
> >of Use Cases for Target Management. Attached document outlines how we see
> >Target Management at Wind River.
> >We are distributing this document in order to
> >
> > - Ensure that interested parties have the same understanding what
Target
> >Management is, what it can do and what it cannot (or will not) do.
> > - Create a common terminology for Target Management.
> > - Make sure that we keep all known desired uses of Target Management
in
> >mind when designing the basic framework.
> >
> >We invite all interested parties to review and comment on the document.
We'd
> >especially like to know if you see anything differently, or you feel that
> >any use cases are missing. Please also let us know if you find some
better
> >terminology for concepts stated, or you'd propose to highlight some other
> >concepts.
> >
> >The goal of this document is to convey the Big Picture of target
management,
> >to ensure that the frameworks we are going to discuss are versatile
enough
> >even though not all use cases may be implemented any time soon.
> >
> >We are looking forward to lots of feedback
> >
> >Thanks,
> >Martin
>
|
|
|
| Re: Use Cases for Target Management [message #608 is a reply to message #594] |
Mon, 13 June 2005 11:52 |
David Dykstal
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
I will try to make the call, and hope you can tolerate my non RTOS
background!
-- Dave
On Fri, 10 Jun 2005 17:01:24 +0200, "Martin Oberhuber"
<martin.oberhuber@windriver.com> wrote:
>Hello David,
>
>thanks a lot for your posting. I've had a look at the presentation you
>mentioned, and I'm sure that RSE would most definitely be interesting for
>the Target Management Project!
>
>* RSE server could be a service plugged in to Target Managent for upload,
>download and remote command
>* RSE views could support Target Management upload, download and remote
>command use cases (when you said "pluggable", I understand that
>communication protocols managed by TM could be used by RSE)
>* RSE's profiles and team-sharing concepts seem to be very interesting, we'd
>need to get more insight to understand these better
>* RSE's re-usable parts for integral Eclipse dialogs seem to be very
>powerful
>
>While RSE currently seems to be centered on file transfer and remote
>command, the Target Management project could extend RSE by
>* supporting standard-based connections like FTP, rsh, ssh such that no
>agent is needed on the remote system
>* supporting OS-less "bare metal" hardware debuggers as connection types
>* retrieving information about OS objects like processes, threads (to allow
>debugger attachment), and potentially information about other resources
>* integrating with Launch Configurations to facilitate program run and debug
>on remote systems.
>* integrating with target registries to support discovery and reservation of
>remote systems
>
>It appears that there is an excellent match for collaboration.
>How can we proceed? Would you like to join the TM conference call on monday?
>
>Thanks,
>Martin Oberhuber, Wind River Systems
>
>
>"David Dykstal" <david_dykstal@us.ibm.com> wrote in message
>news:u94ja156anj75r5vdprrob2hsldtm3h9du@4ax.com...
>> At EclipseCon, IBM presented a poster describing an eclipse-based
>> Remote Systems Explorer that seems to meet several of the goals that
>> are specified in this paper. The component is used in several IBM
>> products, has been shipping for several years, and is available to our
>> business partners. It comes from a different background than these
>> proposals, but there is much in common, particularly since there seems
>> to be a goal of expanding target management support beyond the DSDP
>> space.
>>
>> The underlying framework is pluggable and allows multiple services to
>> be made available from targets based on system type. A developer is
>> therefore be able to work on several types of systems or devices at a
>> time and not be constrained to a common set of services.
>>
>> RSE's demands on target systems can be quite small.
>>
>> We have a presentation (admittedly UI heavy) on our site that
>> describes this.
>>
>> http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
>>
>> We've long considered making this component available. Would this be
>> interesting to this project at all?
>>
>> -- David Dykstal, IBM
>>
>> On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
>> <martin.oberhuber@windriver.com> wrote:
>>
>> >As Rudolf Frauenschuh has announced two weeks ago, we have compiled a
>list
>> >of Use Cases for Target Management. Attached document outlines how we see
>> >Target Management at Wind River.
>> >We are distributing this document in order to
>> >
>> > - Ensure that interested parties have the same understanding what
>Target
>> >Management is, what it can do and what it cannot (or will not) do.
>> > - Create a common terminology for Target Management.
>> > - Make sure that we keep all known desired uses of Target Management
>in
>> >mind when designing the basic framework.
>> >
>> >We invite all interested parties to review and comment on the document.
>We'd
>> >especially like to know if you see anything differently, or you feel that
>> >any use cases are missing. Please also let us know if you find some
>better
>> >terminology for concepts stated, or you'd propose to highlight some other
>> >concepts.
>> >
>> >The goal of this document is to convey the Big Picture of target
>management,
>> >to ensure that the frameworks we are going to discuss are versatile
>enough
>> >even though not all use cases may be implemented any time soon.
>> >
>> >We are looking forward to lots of feedback
>> >
>> >Thanks,
>> >Martin
>>
>
|
|
|
| Re: Use Cases for Target Management [message #566098 is a reply to message #478] |
Tue, 07 June 2005 19:24 |
| Eclipse User |
|
|
|
>The scope of Target Management ends where registered tools like a debugger
>or test
>automation framework take over.
Is it assumed that the access to the register-related information and memory
management is not a part of the target definition and should be provided by
special services like debug agents?
Thanks,
Mikhail Khodjaiants
QNX Software Systems
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d81s4m$29q$1@news.eclipse.org...
> As Rudolf Frauenschuh has announced two weeks ago, we have compiled a list
> of Use Cases for Target Management. Attached document outlines how we see
> Target Management at Wind River.
> We are distributing this document in order to
>
> - Ensure that interested parties have the same understanding what Target
> Management is, what it can do and what it cannot (or will not) do.
> - Create a common terminology for Target Management.
> - Make sure that we keep all known desired uses of Target Management in
> mind when designing the basic framework.
>
> We invite all interested parties to review and comment on the document.
> We'd
> especially like to know if you see anything differently, or you feel that
> any use cases are missing. Please also let us know if you find some better
> terminology for concepts stated, or you'd propose to highlight some other
> concepts.
>
> The goal of this document is to convey the Big Picture of target
> management,
> to ensure that the frameworks we are going to discuss are versatile enough
> even though not all use cases may be implemented any time soon.
>
> We are looking forward to lots of feedback
>
> Thanks,
> Martin
>
> --
> DI Martin Oberhuber
> Member of Technical Staff
> WindRiver, Salzburg, Austria
>
>
>
|
|
|
| Re: Use Cases for Target Management [message #566124 is a reply to message #495] |
Thu, 09 June 2005 10:14 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello Mikhail,
could you clarify a bit more, what you mean by register-related information
and
memory management? What use cases / scenarios do you have in mind?
My first feeling is that accessing CPU registers, which makes sense only
when
the CPU is stopped, would be done by a debugger. Similarly, displaying and
modifying memory regions in a hex editor would also be done by a debugger.
The debugger could, however, use the target definition as a generic data
store
to save target-related setup information.
When you think about JTAG register sets in a hardware emulator, in a sense
that the
emulator needs to load the register definition file before it can connect to
a board, I would
think that the required register definition could be stored with the target
connection
data since it describes the physical structure of the target. The actual
action of loading
the register def into the emulator could be done by a target manager
connection type plugin.
I think it depends a little on how your hardware debugging solution is
structured;
when the hardware box (and the register def) can only be used within the
debugger,
loading the register set could as well be done in the debugger. When the
hardware
box can provide other services "outside a debugging session" as well, it
would make
sense to do this in the target manager.
For memory management, please clarify more.
Thanks,
Martin
"Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
news:d84s9l$pt8$1@news.eclipse.org...
> >The scope of Target Management ends where registered tools like a
debugger
> >or test
> >automation framework take over.
>
> Is it assumed that the access to the register-related information and
memory
> management is not a part of the target definition and should be provided
by
> special services like debug agents?
>
> Thanks,
> Mikhail Khodjaiants
> QNX Software Systems
|
|
|
| Re: Use Cases for Target Management [message #566168 is a reply to message #507] |
Thu, 09 June 2005 15:26 |
| Eclipse User |
|
|
|
Hi Martin,
Thanks for your answer. Sorry, I wasn't clear, the memory management is a
bad example.
The first question is very simple and is about the definitions of CPU
registers, not the access. This information is static. Traditionally the
debug agents are responsible to provide it, which means a running debug
session is needed to get the CPU's registers groups, register names and
types. I would rather expect to have special target services defined for
this and similar purposes as a part of Target Inventory instead of pushing
it to the debug agents.
Thanks,
Mikhail
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d894qj$iho$1@news.eclipse.org...
> Hello Mikhail,
>
> could you clarify a bit more, what you mean by register-related
> information
> and
> memory management? What use cases / scenarios do you have in mind?
>
> My first feeling is that accessing CPU registers, which makes sense only
> when
> the CPU is stopped, would be done by a debugger. Similarly, displaying and
> modifying memory regions in a hex editor would also be done by a debugger.
> The debugger could, however, use the target definition as a generic data
> store
> to save target-related setup information.
>
> When you think about JTAG register sets in a hardware emulator, in a sense
> that the
> emulator needs to load the register definition file before it can connect
> to
> a board, I would
> think that the required register definition could be stored with the
> target
> connection
> data since it describes the physical structure of the target. The actual
> action of loading
> the register def into the emulator could be done by a target manager
> connection type plugin.
>
> I think it depends a little on how your hardware debugging solution is
> structured;
> when the hardware box (and the register def) can only be used within the
> debugger,
> loading the register set could as well be done in the debugger. When the
> hardware
> box can provide other services "outside a debugging session" as well, it
> would make
> sense to do this in the target manager.
>
> For memory management, please clarify more.
>
> Thanks,
> Martin
>
> "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> news:d84s9l$pt8$1@news.eclipse.org...
>> >The scope of Target Management ends where registered tools like a
> debugger
>> >or test
>> >automation framework take over.
>>
>> Is it assumed that the access to the register-related information and
> memory
>> management is not a part of the target definition and should be provided
> by
>> special services like debug agents?
>>
>> Thanks,
>> Mikhail Khodjaiants
>> QNX Software Systems
>
>
|
|
|
| Re: Use Cases for Target Management [message #566241 is a reply to message #517] |
Thu, 09 June 2005 16:20 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello Mikhail,
my first impression was that the register groups, register names and types
were
sufficiently described by knowing the exact CPU variant (as a String). The
CPU
variant would be stored with the target definition and could be retrieved by
target
inventory. A debugger would "know" correct register setup based on the the
CPU
variant.
But if you feel that the full register definition should be stored with the
target definition,
the data structures we define should be versatile enough to allow storing it
as opaque
data which is accessed by custom inventory and debug plugins.
It would be up to plug-in writers to contribute the target inventory
service, property
pages for manual editing (if desired), and debug service for using it. The
framework
we are designing would treat the register definitions as opaque data since I
believe
they would not be used anywhere except the debugger.
Would that fit your needs?
Cheers,
Martin
"Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
news:d89n3u$c4k$1@news.eclipse.org...
> Hi Martin,
>
> Thanks for your answer. Sorry, I wasn't clear, the memory management is a
> bad example.
> The first question is very simple and is about the definitions of CPU
> registers, not the access. This information is static. Traditionally the
> debug agents are responsible to provide it, which means a running debug
> session is needed to get the CPU's registers groups, register names and
> types. I would rather expect to have special target services defined for
> this and similar purposes as a part of Target Inventory instead of pushing
> it to the debug agents.
>
> Thanks,
> Mikhail
>
> "Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
> news:d894qj$iho$1@news.eclipse.org...
> > Hello Mikhail,
> >
> > could you clarify a bit more, what you mean by register-related
> > information
> > and
> > memory management? What use cases / scenarios do you have in mind?
> >
> > My first feeling is that accessing CPU registers, which makes sense only
> > when
> > the CPU is stopped, would be done by a debugger. Similarly, displaying
and
> > modifying memory regions in a hex editor would also be done by a
debugger.
> > The debugger could, however, use the target definition as a generic data
> > store
> > to save target-related setup information.
> >
> > When you think about JTAG register sets in a hardware emulator, in a
sense
> > that the
> > emulator needs to load the register definition file before it can
connect
> > to
> > a board, I would
> > think that the required register definition could be stored with the
> > target
> > connection
> > data since it describes the physical structure of the target. The actual
> > action of loading
> > the register def into the emulator could be done by a target manager
> > connection type plugin.
> >
> > I think it depends a little on how your hardware debugging solution is
> > structured;
> > when the hardware box (and the register def) can only be used within the
> > debugger,
> > loading the register set could as well be done in the debugger. When the
> > hardware
> > box can provide other services "outside a debugging session" as well, it
> > would make
> > sense to do this in the target manager.
> >
> > For memory management, please clarify more.
> >
> > Thanks,
> > Martin
> >
> > "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> > news:d84s9l$pt8$1@news.eclipse.org...
> >> >The scope of Target Management ends where registered tools like a
> > debugger
> >> >or test
> >> >automation framework take over.
> >>
> >> Is it assumed that the access to the register-related information and
> > memory
> >> management is not a part of the target definition and should be
provided
> > by
> >> special services like debug agents?
> >>
> >> Thanks,
> >> Mikhail Khodjaiants
> >> QNX Software Systems
> >
> >
>
>
|
|
|
| Re: Use Cases for Target Management [message #566280 is a reply to message #544] |
Thu, 09 June 2005 18:50 |
| Eclipse User |
|
|
|
As an example I'll describe the situation I am dealing with in the CDT
debugger. The requirement is to add support for user-defined register
groups, i.e. the user selects registers that he/she wants to watch during
the debugging session. This has to be done before launching. The natural way
is to retrieve the list of all CPU registers from the target and make a
selection.
Correct me if I'm wrong, but in your scenario the CDT debugger should keep
the list of CPU variants with the corresponding register defintions. My
suggestion is to make the target responsible for providing this information.
This could be iimplemented as a data store inside the target management
plugins or somehow else, but an API is needed to provide access to this
information.
"Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
news:d89q7n$gjl$1@news.eclipse.org...
> Hello Mikhail,
>
> my first impression was that the register groups, register names and types
> were
> sufficiently described by knowing the exact CPU variant (as a String). The
> CPU
> variant would be stored with the target definition and could be retrieved
> by
> target
> inventory. A debugger would "know" correct register setup based on the the
> CPU
> variant.
>
> But if you feel that the full register definition should be stored with
> the
> target definition,
> the data structures we define should be versatile enough to allow storing
> it
> as opaque
> data which is accessed by custom inventory and debug plugins.
>
> It would be up to plug-in writers to contribute the target inventory
> service, property
> pages for manual editing (if desired), and debug service for using it. The
> framework
> we are designing would treat the register definitions as opaque data since
> I
> believe
> they would not be used anywhere except the debugger.
>
> Would that fit your needs?
>
> Cheers,
> Martin
>
>
> "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> news:d89n3u$c4k$1@news.eclipse.org...
>> Hi Martin,
>>
>> Thanks for your answer. Sorry, I wasn't clear, the memory management is a
>> bad example.
>> The first question is very simple and is about the definitions of CPU
>> registers, not the access. This information is static. Traditionally the
>> debug agents are responsible to provide it, which means a running debug
>> session is needed to get the CPU's registers groups, register names and
>> types. I would rather expect to have special target services defined for
>> this and similar purposes as a part of Target Inventory instead of
>> pushing
>> it to the debug agents.
>>
>> Thanks,
>> Mikhail
>>
>> "Martin Oberhuber" <martin.oberhuber@windriver.com> wrote in message
>> news:d894qj$iho$1@news.eclipse.org...
>> > Hello Mikhail,
>> >
>> > could you clarify a bit more, what you mean by register-related
>> > information
>> > and
>> > memory management? What use cases / scenarios do you have in mind?
>> >
>> > My first feeling is that accessing CPU registers, which makes sense
>> > only
>> > when
>> > the CPU is stopped, would be done by a debugger. Similarly, displaying
> and
>> > modifying memory regions in a hex editor would also be done by a
> debugger.
>> > The debugger could, however, use the target definition as a generic
>> > data
>> > store
>> > to save target-related setup information.
>> >
>> > When you think about JTAG register sets in a hardware emulator, in a
> sense
>> > that the
>> > emulator needs to load the register definition file before it can
> connect
>> > to
>> > a board, I would
>> > think that the required register definition could be stored with the
>> > target
>> > connection
>> > data since it describes the physical structure of the target. The
>> > actual
>> > action of loading
>> > the register def into the emulator could be done by a target manager
>> > connection type plugin.
>> >
>> > I think it depends a little on how your hardware debugging solution is
>> > structured;
>> > when the hardware box (and the register def) can only be used within
>> > the
>> > debugger,
>> > loading the register set could as well be done in the debugger. When
>> > the
>> > hardware
>> > box can provide other services "outside a debugging session" as well,
>> > it
>> > would make
>> > sense to do this in the target manager.
>> >
>> > For memory management, please clarify more.
>> >
>> > Thanks,
>> > Martin
>> >
>> > "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
>> > news:d84s9l$pt8$1@news.eclipse.org...
>> >> >The scope of Target Management ends where registered tools like a
>> > debugger
>> >> >or test
>> >> >automation framework take over.
>> >>
>> >> Is it assumed that the access to the register-related information and
>> > memory
>> >> management is not a part of the target definition and should be
> provided
>> > by
>> >> special services like debug agents?
>> >>
>> >> Thanks,
>> >> Mikhail Khodjaiants
>> >> QNX Software Systems
>> >
>> >
>>
>>
>
>
|
|
|
| Re: Use Cases for Target Management [message #566302 is a reply to message #478] |
Fri, 10 June 2005 13:31 |
David Dykstal
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
At EclipseCon, IBM presented a poster describing an eclipse-based
Remote Systems Explorer that seems to meet several of the goals that
are specified in this paper. The component is used in several IBM
products, has been shipping for several years, and is available to our
business partners. It comes from a different background than these
proposals, but there is much in common, particularly since there seems
to be a goal of expanding target management support beyond the DSDP
space.
The underlying framework is pluggable and allows multiple services to
be made available from targets based on system type. A developer is
therefore be able to work on several types of systems or devices at a
time and not be constrained to a common set of services.
RSE's demands on target systems can be quite small.
We have a presentation (admittedly UI heavy) on our site that
describes this.
http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
We've long considered making this component available. Would this be
interesting to this project at all?
-- David Dykstal, IBM
On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
<martin.oberhuber@windriver.com> wrote:
>As Rudolf Frauenschuh has announced two weeks ago, we have compiled a list
>of Use Cases for Target Management. Attached document outlines how we see
>Target Management at Wind River.
>We are distributing this document in order to
>
> - Ensure that interested parties have the same understanding what Target
>Management is, what it can do and what it cannot (or will not) do.
> - Create a common terminology for Target Management.
> - Make sure that we keep all known desired uses of Target Management in
>mind when designing the basic framework.
>
>We invite all interested parties to review and comment on the document. We'd
>especially like to know if you see anything differently, or you feel that
>any use cases are missing. Please also let us know if you find some better
>terminology for concepts stated, or you'd propose to highlight some other
>concepts.
>
>The goal of this document is to convey the Big Picture of target management,
>to ensure that the frameworks we are going to discuss are versatile enough
>even though not all use cases may be implemented any time soon.
>
>We are looking forward to lots of feedback
>
>Thanks,
>Martin
|
|
|
| Re: Use Cases for Target Management [message #566356 is a reply to message #570] |
Fri, 10 June 2005 15:01 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hello David,
thanks a lot for your posting. I've had a look at the presentation you
mentioned, and I'm sure that RSE would most definitely be interesting for
the Target Management Project!
* RSE server could be a service plugged in to Target Managent for upload,
download and remote command
* RSE views could support Target Management upload, download and remote
command use cases (when you said "pluggable", I understand that
communication protocols managed by TM could be used by RSE)
* RSE's profiles and team-sharing concepts seem to be very interesting, we'd
need to get more insight to understand these better
* RSE's re-usable parts for integral Eclipse dialogs seem to be very
powerful
While RSE currently seems to be centered on file transfer and remote
command, the Target Management project could extend RSE by
* supporting standard-based connections like FTP, rsh, ssh such that no
agent is needed on the remote system
* supporting OS-less "bare metal" hardware debuggers as connection types
* retrieving information about OS objects like processes, threads (to allow
debugger attachment), and potentially information about other resources
* integrating with Launch Configurations to facilitate program run and debug
on remote systems.
* integrating with target registries to support discovery and reservation of
remote systems
It appears that there is an excellent match for collaboration.
How can we proceed? Would you like to join the TM conference call on monday?
Thanks,
Martin Oberhuber, Wind River Systems
"David Dykstal" <david_dykstal@us.ibm.com> wrote in message
news:u94ja156anj75r5vdprrob2hsldtm3h9du@4ax.com...
> At EclipseCon, IBM presented a poster describing an eclipse-based
> Remote Systems Explorer that seems to meet several of the goals that
> are specified in this paper. The component is used in several IBM
> products, has been shipping for several years, and is available to our
> business partners. It comes from a different background than these
> proposals, but there is much in common, particularly since there seems
> to be a goal of expanding target management support beyond the DSDP
> space.
>
> The underlying framework is pluggable and allows multiple services to
> be made available from targets based on system type. A developer is
> therefore be able to work on several types of systems or devices at a
> time and not be constrained to a common set of services.
>
> RSE's demands on target systems can be quite small.
>
> We have a presentation (admittedly UI heavy) on our site that
> describes this.
>
> http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
>
> We've long considered making this component available. Would this be
> interesting to this project at all?
>
> -- David Dykstal, IBM
>
> On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
> <martin.oberhuber@windriver.com> wrote:
>
> >As Rudolf Frauenschuh has announced two weeks ago, we have compiled a
list
> >of Use Cases for Target Management. Attached document outlines how we see
> >Target Management at Wind River.
> >We are distributing this document in order to
> >
> > - Ensure that interested parties have the same understanding what
Target
> >Management is, what it can do and what it cannot (or will not) do.
> > - Create a common terminology for Target Management.
> > - Make sure that we keep all known desired uses of Target Management
in
> >mind when designing the basic framework.
> >
> >We invite all interested parties to review and comment on the document.
We'd
> >especially like to know if you see anything differently, or you feel that
> >any use cases are missing. Please also let us know if you find some
better
> >terminology for concepts stated, or you'd propose to highlight some other
> >concepts.
> >
> >The goal of this document is to convey the Big Picture of target
management,
> >to ensure that the frameworks we are going to discuss are versatile
enough
> >even though not all use cases may be implemented any time soon.
> >
> >We are looking forward to lots of feedback
> >
> >Thanks,
> >Martin
>
|
|
|
| Re: Use Cases for Target Management [message #566384 is a reply to message #594] |
Mon, 13 June 2005 11:52 |
David Dykstal
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
I will try to make the call, and hope you can tolerate my non RTOS
background!
-- Dave
On Fri, 10 Jun 2005 17:01:24 +0200, "Martin Oberhuber"
<martin.oberhuber@windriver.com> wrote:
>Hello David,
>
>thanks a lot for your posting. I've had a look at the presentation you
>mentioned, and I'm sure that RSE would most definitely be interesting for
>the Target Management Project!
>
>* RSE server could be a service plugged in to Target Managent for upload,
>download and remote command
>* RSE views could support Target Management upload, download and remote
>command use cases (when you said "pluggable", I understand that
>communication protocols managed by TM could be used by RSE)
>* RSE's profiles and team-sharing concepts seem to be very interesting, we'd
>need to get more insight to understand these better
>* RSE's re-usable parts for integral Eclipse dialogs seem to be very
>powerful
>
>While RSE currently seems to be centered on file transfer and remote
>command, the Target Management project could extend RSE by
>* supporting standard-based connections like FTP, rsh, ssh such that no
>agent is needed on the remote system
>* supporting OS-less "bare metal" hardware debuggers as connection types
>* retrieving information about OS objects like processes, threads (to allow
>debugger attachment), and potentially information about other resources
>* integrating with Launch Configurations to facilitate program run and debug
>on remote systems.
>* integrating with target registries to support discovery and reservation of
>remote systems
>
>It appears that there is an excellent match for collaboration.
>How can we proceed? Would you like to join the TM conference call on monday?
>
>Thanks,
>Martin Oberhuber, Wind River Systems
>
>
>"David Dykstal" <david_dykstal@us.ibm.com> wrote in message
>news:u94ja156anj75r5vdprrob2hsldtm3h9du@4ax.com...
>> At EclipseCon, IBM presented a poster describing an eclipse-based
>> Remote Systems Explorer that seems to meet several of the goals that
>> are specified in this paper. The component is used in several IBM
>> products, has been shipping for several years, and is available to our
>> business partners. It comes from a different background than these
>> proposals, but there is much in common, particularly since there seems
>> to be a goal of expanding target management support beyond the DSDP
>> space.
>>
>> The underlying framework is pluggable and allows multiple services to
>> be made available from targets based on system type. A developer is
>> therefore be able to work on several types of systems or devices at a
>> time and not be constrained to a common set of services.
>>
>> RSE's demands on target systems can be quite small.
>>
>> We have a presentation (admittedly UI heavy) on our site that
>> describes this.
>>
>> http://www.developer.ibm.com/isv/rational/remote_system_expl orer.html
>>
>> We've long considered making this component available. Would this be
>> interesting to this project at all?
>>
>> -- David Dykstal, IBM
>>
>> On Mon, 6 Jun 2005 18:03:32 +0200, "Martin Oberhuber"
>> <martin.oberhuber@windriver.com> wrote:
>>
>> >As Rudolf Frauenschuh has announced two weeks ago, we have compiled a
>list
>> >of Use Cases for Target Management. Attached document outlines how we see
>> >Target Management at Wind River.
>> >We are distributing this document in order to
>> >
>> > - Ensure that interested parties have the same understanding what
>Target
>> >Management is, what it can do and what it cannot (or will not) do.
>> > - Create a common terminology for Target Management.
>> > - Make sure that we keep all known desired uses of Target Management
>in
>> >mind when designing the basic framework.
>> >
>> >We invite all interested parties to review and comment on the document.
>We'd
>> >especially like to know if you see anything differently, or you feel that
>> >any use cases are missing. Please also let us know if you find some
>better
>> >terminology for concepts stated, or you'd propose to highlight some other
>> >concepts.
>> >
>> >The goal of this document is to convey the Big Picture of target
>management,
>> >to ensure that the frameworks we are going to discuss are versatile
>enough
>> >even though not all use cases may be implemented any time soon.
>> >
>> >We are looking forward to lots of feedback
>> >
>> >Thanks,
>> >Martin
>>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:38:16 GMT 2024
Powered by FUDForum. Page generated in 0.03825 seconds |
] 
Search
Help
Register
Login
Home
