From:
dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ken Ryall
Sent: Monday, April 28, 2008 1:41 PM
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: [dsdp-tm-dev] TCF feedback
Hi,
I’ve been reviewing all of the material I can find about the target
communications framework (TCF) project. Looks like a nice job overall, but my
understanding remains fuzzy in a few areas:
What if you had multiple agents running on the same host? They would need to
use different ports and so perhaps would not be discoverable? And if they were
not discoverable is there some way to connect to them directly?
We solve this issue by having
the first TCF server to use the “standard TCF” port number, we call
this the discovery master, and all subsequent TCF servers on the same host will
use a dynamic port number. The subsequent TCF servers will connect to the
discovery master to publish their discovery information. When the discovery
master disappears for any reason then one of the other TCF servers will try to
become the master.
It looks like you might have agents
providing various services running on the host or target or both. Some of the
services in the reference agent (symbols, expressions) seem like they are
things you would do on the host while others (run control, memory, registers)
you would do on the target. When debugging on the host only all those could be rolled
into one agent but otherwise it seems like you would need to split them up.
You are right, the agent prototype
does implement some things that would normally be done on the host e.g.
symbols/line number information. This was done to prototype the service
and to test the DSF integration. Clearly in a resource constrained
embedded system you would not implement those services on the target, but the
idea is that the same service interface would be use, so clients would not see
any difference.
I understand the reference agent is written
in plain vanilla C code to facility scaling down to simple devices. But if I
were writing an agent that was intended to live host side or for more robust
targets I would prefer to write it in C++. Are they any issues with writing an
agent in C++?
I don’t see any technical
issues with writing an agent in C++. We just chose to use C because we need
to be able to be able to run the agent in the kernel and on interrupt level and
for this C is more suitable.
It seems like if you currently had a debug agent on a target you could convert
it into a TCF agent and just revise the host side stuff that talks to it. That
would open it up to other tools that support the TCF protocol. Do I have that
right?
Yes, the implementation
should not matter as long as the protocol is followed. It would probably
be good to have a protocol validation test suite to make sure multiple
implementations are functional.
Thanks,
Felix
Thanks - Ken