Re: Fwd: staprun-only system

[David Smith <dsmith at redhat dot com>]

Mike Anderson wrote:
> David Smith <dsmith@redhat.com> wrote:
>> Mike Anderson wrote:
>>> David Smith <dsmith@redhat.com> wrote:
>>>> Assuming you are using an rpm-based system, here's what you should do.
>>>> Install your distro-supplied 'systemtap-runtime' rpm on the target system.
>>>>
>>>> If you want the latest .git version, you would do something like the
>>>> following on your build system:
>>>>
>>>> 1.) Pull latest systemtap git tree.
>>>> 2.) Generate tar file from git tree
>>>> 3.) Run rpmbuild on the tar file and spec file.  Something like:
>>>>     # rpmbuild --define "_topdir `pwd`" --define "_sourcedir `pwd`" -bb
>>>> systemtap.spec
>>>> 4.) Copy RPMS/{ARCH}/systemtap-runtime-*.rpm to the target system
>>>> 5.) Install the systemtap-runtime rpm on the target system.
>>>> 6.) Install RPMS/{ARCH}/systemtap-* rpms on the build system (minus the
>>>> debuginfo rpm and probably the testsuite rpm)
>>>>
>>>> Now you have matching systemtap versions on both your build and target
>>>> systems.
>>>>
>>> Thanks for the response. While this is an option I was trying to avoid
>>> setting up build environments matching all the test machines that I have.
>>> The test systems may be of more than one distro type and library versions.
>> You might be making more work for yourself in trying to avoid setting up
>> build environments.  Besides setting up actual machines to match all
>> your environments, there are other options of mock or virtual machines.
>>
> 
> I have not used mock personally, but will look into this. I currently
> setup up virtual machines (recent fan of thincrust), but mainly for
> testing kernels using pseudo storage devices.
> 
>>>> If you aren't using an rpm-based system, I'd basically mimic what the
>>>> spec file does.  Configure and build, then copy the files mentioned in
>>>> the '%files runtime' section over to the target system.
>>> In my previous example my configure and make steps where pretty close to
>>> the what the spec file is doing. Copying the runtime files over to the
>>> target system assumes that they are like enough that the commands will
>>> run.
>> I'm confused.  Are you only building once and then deploying on multiple
>> target platforms?
> 
> Currently I will build a kernel for one arch (in this example the arch is
> x86_64) then I will rsync the kernel to a number of target systems. As
> indicted some target systems will contain different distros. Since I am
> only dealing with a kernel this process there is normally no issue with
> this method.
> 
> My goal with these steps was to build up tapsets by using them during
> kernel development work (vs. coding debugfs interfaces or utilizing other
> kernel debug / trace infrastructure). Then in future situations where I
> may need a system tape script for a customer issue I can possible draw
> from this group of tapsets or pull fragments from these tapsets.
> 
> I know my usage model may not be the common usage model for systemtap. I
> was just trying to see if I can increase the utility of systemtap for me
> and maybe obtain info on how best to use it in a kernel development
> environment.

Systemtap is a user-space exe, that builds and runs kernel modules.
Because it is a user-space exe, you are going to have trouble building
it on one distro and copying it to a different distro (just as you would
any other user-space exe).  If you want to do this, your best bet is to
build it on a system with the lowest version of glibc (and other
libraries) and install any needed compat libraries on the other distros.

Building on F9 and deploying on F10 should probably work.  Building on
F9 and trying to deploy on SLES - you might get lucky and you might not.
 This is certainly not a "supported" or recommended procedure.

Your tapset scripts should work across different distros with no
problems (except for differences in architecture) when run against the
same kernel.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)