Re: [RFC] SystemTap future direction

[Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>]

> 
> Yes. I was at GUADEC last week and was happily surprised to meet
> multiple Gnome hackers who were happy systemtap users. glib and gobject
> have their own static markers (dtrace compatible) and tapsets now.
> 

This is nice to hear. Probably would it help if some of these folks
talk about how they used SystemTap with some key kernel developers
whenever they meet let say in conferences like say Plumbers, end
user summits etc ??

> > I'd like to suggest some directions here;
> > 
> > - Merge runtime and module-source generator into linux kernel.
> >  This will requires rewriting whole of systemtap code from C++ to
> >  C or other LL (perl or python)
> 
> If that requires rewriting the whole translator that seems very
> unattractive. The translator is just the script parser and translator,
> so I don't see why it matters what language it is written in. But
> merging some of the runtime, specifically the utrace/task-finder code so
> it can be reused by others to get better user space task/process
> observability seems like a nice thing to have.
> 

I think the task-finder would be gated by utrace.
I am working on a file based uprobing stuff that provides very
minimal task-finder like features.

> 
> The kernel maintainers can make our lives easier by letting us upstream
> more stuff that we can then reuse. But if not, we can upstream and still
> carry our own copy if necessary. That is far from ideal, but if it is
> the only option, at least the user experience wouldn't be worse than
> what we have now. But I hope we can convince them otherwise of course.
> 

But Mark, that may not provide the out-of-box experience that most
of the users esp the first timers would look for. And it would
certainly cap our users.