[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [linuxtools-dev] oprofile on remote targets
|
On 06/10/2011 07:43 PM, Anna Dushistova wrote:
On Jun 11, 2011, at 2:36 AM, Siva Velusamy wrote:
Thanks everyone for your responses. Jeff - see comments inline:
Anna has a good point in that we should use RSE. I am going to
open a bug to rewrite the Valgrind remote plugin to use RSE
instead of calling TCF directly. There is an RSE connector for TCF.
I would like to purse cleaning up the TCF remote launch as I feel
that TCF is quite extensible and the current sample agent has
pretty well everything we need as evidenced by the remote Valgrind
work. I want to change the design so it runs under a regular
userid (instead of root as it does now). To handle any required
root access (such as opcontrol), the idea is to use PolicyKit
pkexec and have policy files installed on the remote system for
these special commands. If we keep the design that installs an rpm
on the remote system, this is straightforward to do.
I will open a bug for remote OProfile as well. It would be great
if you want to take on this work or collaborate. I personally want
to start on converting over the remote Valgrind plug-in to use RSE.
I haven't looked at the TCF/RSE integration, but from the emails it
sounds like RSE might sit on top of TCF and we should be using RSE for
all the remote target interaction. I'm certainly willing to
collaborate on this in the context of oprofile.
RSE(Remote Systems Explorer) supports different connection protocols
including ssh and TCF. At the moment I don't envision anything in the
oprofile plugin interaction with remote Linux target that requires some
specific protocol.
Correct.
Right now the part about installing rpm's, and the permission settings
are not that relevant to us since we assume that the remote target is
running a version of Linux with the root file system as supplied by
us. And we plan to have all the dependencies already available on this
root file system.
3. I also think that this should work fine on a Windows host,
as long as
the binary is compiled on Windows (and debug symbols in the
binary can
be mapped back to source).
OProfile is not on Windows. What do you mean by this?
I meant to ask if there any significant obstacle in having Eclipse
running on a Windows host communicating via RSE to the remote embedded
target running Linux. Specifically, we are talking about cross
compiling applications on Windows/Linux x86 to target running ARM
Linux. The ARM Linux system will have oprofile and other dependencies
like TCF agent (if necessary) already available.
I don't think so.
4. I was initially thinking of a custom framework to
communicate to the
target, but a few recent threads on this list seem to indicate
that this
should be done using TCF. I haven't used TCF before - if
someone could
confirm that TCF is appropriate for this use case, that'll be
greatly
appreciated.
That's the path we're currently heading down. It doesn't make
sense to create a new framework. TCF is Open Source, extensible,
and we already have proof of concept with remote Valgrind and
LTTng. There are a number of areas that need to be cleaned up
including set-up. In theory, we would have a special rpm that
would install on the remote host. The rpm would install and run
the agent as well as prereq various tools and install PolicyKit
policy files. There's nothing to say we can't switch later to
something else or allow other alternatives to TCF.
So I'm a bit confused about RSE and TCF. I got the impression that we
can use RSE which uses TCF underneath. Do you see the oprofile plugins
directly having a dependency on TCF or only on RSE?
I would like to second this question.
Sorry for the confusion. RSE can use TCF underneath. From the
perspective of coding a remote OProfile solution, you and Anna are
correct in that this should be done via RSE.
5. I'm going to ignore all discussions regarding PolicyKit etc
initially. I assume that these proposed changes shouldn't
significantly
impact future support for that.
It does have some bearing. The current code expects to find a
special opcontrol executable/script in the native/scripts
directory. This is currently set up by the install.sh script and
right now uses consoleHelper which is being obsoleted. There is a
bug to replace this with PolicyKit which is waiting on a CQ for
approval. For running opcontrol remotely, we might as well call
pkexec directly and specify /usr/bin/opcontrol. This assumes we
have a policy file installed on the remote system which is part of
the set-up design I was talking about earlier.
That makes sense. I obviously have no objections to this, but I want
to see something working as fast as possible. So for the first
prototype, we could possibly ignore this.
My plan was to get something working, and then file a bugzilla entry
with patches, maybe in a week or two. Does that work?
-Siva
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx <mailto:linuxtools-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev