This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Discussion at Linux Foundation Japan Symposium
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Theodore Tso <tytso at mit dot edu>, systemtap at sources dot redhat dot com
- Date: Mon, 12 Jan 2009 14:29:41 -0500
- Subject: Re: Discussion at Linux Foundation Japan Symposium
- References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081223211306.67D29FC3B7@magilla.sf.frob.com> <20081223223217.GW23723@mit.edu> <49518856.80907@redhat.com> <20090110024810.GL23869@mit.edu> <20090111162912.GC18407@redhat.com> <496B894D.7000708@redhat.com> <20090112185217.GE18407@redhat.com>
Hi Frank,
Frank Ch. Eigler wrote:
> Hi -
>
> On Mon, Jan 12, 2009 at 01:17:49PM -0500, Masami Hiramatsu wrote:
>> [...]
>> Frank Ch. Eigler wrote:
>>> That is one possible solution for this specific problem -- rawhide
>>> systemtap users who're unable/unwilling to build systemtap out of git
>>> occasoinally. (Remember that the recent 2.6.28 breakage took a few
>>> hours to fix.)
>>>
>>> Another solution would be for rawhide-style distributions to
>>> aggressively package systemtap snapshots into their development
>>> streams [...]
>> Even if we do that, we have to clarify which package can be applied
>> to which kernel version.
>
> In what way? There would be one package in rawhide, which should work
> on every kernel version that we've ever worked with. It would be
> replaced frequently - perhaps every few days.
For example, commenting in each snapshot release note.
e.g. - tested on 2.6.28.
>> I'm still not sure when some bugs reported on this ml are fixed -
>> e.g. http://sources.redhat.com/ml/systemtap/2009-q1/msg00029.html
>
> There was no bugzilla report associated with it, but it was fixed the
> same day.
Thank you. I think we should notice that fix to reporters.
>> BTW, more those kind of bugfix are committed, more autoconfs are
>> introduced. We already has 15(!) autoconfs,
>
> Yes, but as you know, their cost has a benefit: they enable our
> operation with a whole spectrum of kernel versions.
I know that it is so useful for older kernels. However, once the
runtime is merged to upstream, we don't need to prepare those autoconfs
and to recompile systemtap itself.
>> and these autoconfs increase compilation time (this will be avoided
>> by caching the result per kernel...).[...]
>
> FWIW, on my workstation, they seem to add about a second.
Sure, autoconf compilation overhead may not be so big problem...
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com