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. > > 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. > > > 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@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
