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.
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. > > 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? > > 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
