Re: Discussion at Linux Foundation Japan Symposium

[fche at redhat dot com (Frank Ch. Eigler)]

Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com> writes:

> [...]  Utrace and uprobe features are currently available only on
> Fedora and Red Hat Enterprise Linux, since those patches are not
> merged into upstream kernel yet.

That's correct, but we all hope this is temporary.  Both utrace and
uprobes developers are keen to push the work into the kernel ASAP.

> To reduce complaints of upstream kernel developers, systemtap
> project may need to postpone adding new uprobe features until
> getting utrace (and uprobe) patch set accepted in mainline.

I am not sure I understand - surely kernel developers are not offended
by our delightful and necessary progress in user-space probing.  Even
if they were, the cure for that is not for us to stop development in
systemtap proper, but for them and others to offer support for
utrace/uprobes to get that code upstream.


> (2) Maintain tapset

> Systemtap users (including kernel developers) get frustrated because
> tapsets often do not work on the latest kernel.

It would be very helpful if people who run into actual problems got in
touch with us.  It is disheartening to hear of someone trying to run
systemtap against some kernel versions, failing for some reason, and
giving up instead of asking for help or reporting the bug.


> my suggestion:
>
> If systemtap project can fix this kind of incompatibilities
> within a few hours or days as Myths about systemtap 
> on the wiki claims, releasing new systemtap minor release
> tarball for each upstream kernel release would help users.

That particular myth entry was more about runtime incompatibilities
that prevent building at all.  Those things are indeed fixed quickly.
Do you think that snapshots even more frequent than the weekly
snapshots are likely to be used?  Or perhaps we could tag the git tree
with kernel release numbers that it has been tested against.

Script tapsets are somewhat fuzzier, in that we may have one or two
test suite failures but nothing catastrophic happen if they go
out-of-date.  At the kernel summit the preferred solution appeared to
be to have kernel people insert static more instrumentation that we
could also use.


> (3) Make no debuginfo version

> Systemtap always requires kernel debuginfo to use.  Unfortunately,
> it is hard for users of some distributions to have debuginfo.

Those distributions ought to be lobbied to improve this situation,
since there are many non-systemtap uses of debugging data - such as
debuggers, kernel- and user-space crash dump analysis tools.

> my suggestion:
>
> If systemtap has a build option to make no debuginfo version,
> this complain will be reduced. I know we had had it before.
> We should provide it again.

The limitations of operating without debugging information are severe,
but indeed we should revive this functionality.

If tools appear to package CTF-like debuginfo subsets, and if linux
developers/distributors are willing to use them, systemtap should of
course support it too.


- FChE