This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: runtime transport changes
- From: Tom Zanussi <zanussi at us dot ibm dot com>
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 19 Aug 2005 10:31:22 -0500
- Subject: Re: runtime transport changes
- References: <1124452809.18297.11.camel@dragon>
Martin Hunt writes:
> I've checked in the following changes to stpd and the runtime transport.
>
> 1. Netlink is conpletely removed. It has been replaced with a
> filesystem-based transport that lives in /proc/systemtap. This is now
> the default.
>
> 2. To use relayfs, you define STP_RELAYFS. See shellsnoop.c for an
> example.
>
> 3. stp-control.ko is gone.
>
> 4. The "stp" scripts are gone. Just run "stpd modulename". stpd will
> attempt to find a script named "stp_check" to compile and load the
> relayfs module if it isn't already loaded. The rpm puts stp_check
> in /usr/libexec/systemtap, but if you are running a stpd that wasn't
> built as part of an rpm, it won't know to look there. Copy it (or link
> to it) to your path somewhere. The relayfs module will currently get
> loaded even if it is never used.
>
> 5. Relayfs doesn't work on rawhide kernels, but the new transport works
> fine.
What you mean is systemtap doesn't work with relayfs on rawhide
kernels, not that relayfs itself doesn't work, right? I don't know
what version of relayfs is in rawhide, but it should work fine for
anything written to the corresponding API.
I can update the systemtap transport to use whichever API is present
on the target system, but I'm not sure about the best way to do it -
currently we have 3 places to look for relayfs - the relayfs in
systemtap/runtime/relayfs (actually shouldn't this be removed? Why is
it still there if relayfs is in the kernel?), the relayfs in the RHEL
kernel fs/relayfs, which is the same, and the relayfs in rawhide
fs/relayfs (I'm assuming relayfs is in rawhide) or some other kernel
being used on the system such as rc5-mm1, with the latest relayfs and
API changes. The only way I know to distinguish which version of
relayfs is being used on the system is to look at
RELAYFS_CHANNEL_VERSION in /include/linux/relayfs_fs.h - for the old
API that will be 3 and for the new > 3. So I guess I'd need to put a
couple ifdefs with RELAYFS_VERSION > 3 in the transport code, and then
have the build find out from relayfs_fs.h which version to use in the
compilation. Let me know if you have any other ideas on this.
Thanks,
Tom