Skip to main content
[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

Back to the top