This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Discussion at Linux Foundation Japan Symposium
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Theodore Tso <tytso at mit dot edu>, systemtap at sources dot redhat dot com
- Date: Mon, 12 Jan 2009 13:52:17 -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>
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.
> 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.
> 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.
> 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.
> >> and eventually I suspect markers infrastructure will probably
> >> disappear entirely since tracepoints are perceived as better and
> >> as their replacement.
> >
> > (That would probably hurt lttng more than it would systemtap.)
>
> (Now, lttng is working with kernel community, I think this doesn't hurt
> lttng so much.)
I'm simply saying that currently lttng thoroughly depends on markers,
which systemtap does not.
- FChE