This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: staprun-only system


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.

Thanks,

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]