This is the mail archive of the systemtap@sourceware.org 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: [RFC] SystemTap future direction


Mark Wielaard wrote:
> On Wed, 2010-08-04 at 15:06 +0530, 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 don't know if these users and kernel hackers hang out at the same
> conferences. But there have been some blog posts by people using
> systemtap for these kind of static markers in gnome libraries:
> http://tecnocode.co.uk/2010/07/13/reference-count-debugging-with-systemtap/
> http://blogs.gnome.org/alexl/2010/01/04/tracing-glib/

Hm, these are very interesting stories.
We should let kernel people know that application people already start
using systemtap/dtrace in there developing process.


>>> 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.
> 
> I am not saying it is ideal. But it wouldn't be worse than the current
> experience. If the kernel maintainers really don't want to export the
> functionality and we don't want to ship a parallel module of our own,
> then we could also use the exported kallsyms support in newer kernels to
> call the function addresses directly. That might actually be slightly
> nicer for the user, although a bit more fragile.

Uh, that's really really the last resort.
We have to talk about what is the best way for users with kernel people
and try hard to find out how to compromise as far as we can.

Thank you,

> 
> Cheers,
> 
> Mark
> 

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


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