Discussion at Linux Foundation Japan Symposium

[Masami Hiramatsu]

Hi

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 -- as some are doing already.  (We could have semiautomated
> snapshots going straight into fedora rawhide too, and could increase
> the rate of minor releases.)

Even if we do that, we have to clarify which package can be applied
to which kernel version. 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

BTW, more those kind of bugfix are committed, more autoconfs are
introduced. We already has 15(!) autoconfs, and these autoconfs
increase compilation time (this will be avoided by caching the result
per kernel...).

I think current method is good for short-term solution, but that
obviously has a limit.


>> *) Systemtap needs to be adpted to use tracepoints, quickly [...]
> 
> We will work on this very soon.

That's a good news!

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

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com