Re: [RFC] SystemTap future direction

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

Srikar Dronamraju wrote:
>> 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'm asking some systemtap users in Japan to join us at
LinuxCon Japan, tracing track. I found some PostgreSQL
developers who are using systemtap for profiling transactions
instead of Dtrace ;)

So, we may be able to convince kernel people if we can bring
systemtap users voice to them. If they know not only kernel
developers but also application developers and users use
systemtap, they need to consider features for those users.

>>> 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.

Nice! :)

Thank you,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com