This is the mail archive of the
mailing list for the systemtap project.
Re: Discussion at Linux Foundation Japan Symposium
Theodore Tso wrote:
> May I gently suggest that if SystemTap project had been more
> aggressively making SystemTap usable for kernel developers, and it had
> an active user community that included may more LKML denizens, that
> perhaps these bugs might have been fixed more quickly? I don't know
> how to make a better case that an attitude of "kernel developers don't
> matter; our primary customers are enterprise end users" is in the end
> quite self-defeating.
OK, so I would like to hear your suggestions seriously.
(I believe that we know on what we are working).
I think it's time to embody action items. Just criticizing can't go
things ahead. So, what we can do for you?
- Communication issue
- Notifying releasing on LKML frequently.
- Preparing more documents for kernel developers.
- Feeding back kernel developers' opinions.
- Solving debuginfo issue
- in the short term, notifying how to minimize debuginfo size.
- in the mid term, making dummy (function-entry) debuginfo.
- in the long term, Roland's dwarf compressor can solve this issue.
- Upstream first issue
- Develop code on LKML and embrace feedbacks.
- Involving main kernel maintainer to speed up the code merging.
- Systemtap itself
- Merging a part of runtime and basic tapset to kernel tree, which
will provide us a permanent API for systemtap generated code.
(BTW, I'd like to suggest modifying ftrace plug-able and systemtap
generating ftrace-plugin tracers. This will be more acceptable for
upstream because we don't need to add so many code).
Any other issues and ideas?
>> (It so happens this refocusing of my time is intended to jump-start
>> the DWARF size reduction work. I won't deny this may well be "12-18
>> months out" for stable release deployments, but it can't even be
>> that if it doesn't start sometime, and this is an approach to the
>> debuginfo issues that most people other than Ted seem to agree could
>> solve many important problems for systemtap.)
> I agree it would solve many problems for SystemTap, I just don't see
> it reaching fruition until RHEL 7, and there is such a thing as
> missing the window, where projects get defunded by companies, and
> kernel developers start working on alternate schemes (like ftrace and
> LTTng) because they've given up on SystemTap. I would probably be
> making similar recommendations at my company, except that I see the
> potential in SystemTap, and realize there are may things that these
> alternate solutions would not be able to do --- for example, Userspace
> Tracing, filtering log decisions in kernel space, etc. It's just been
> frustrating seeing a project with so much potential not living up to
> that potential.
It's a nightmare scenario :(. I hope we can avoid it.
Hitachi Computer Products (America) Inc.
Software Solutions Division