This is the mail archive of the 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: Discussion at Linux Foundation Japan Symposium

Hi Ted,

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
 - Utrace/Uprobe
  - 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.

Thank you,

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division


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