[ltt-dev] [PATCH v2] add tracepoints of panic and kexec

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
> Mathieu Desnoyers wrote:
> > * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> * From: "Mathieu Desnoyers" <compudj@krystal.dyndns.org>
> >>> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >>>> * From: "Mathieu Desnoyers" <compudj@krystal.dyndns.org>
> >>>>> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >>>>>> Instrumentation of following panic and kexec related events are added:
> >>>>>> panic
> >>>>>> kernel_kexec
> >>>>>> crash_kexec
> >>>>>>
> >>>>>> It is useful for build flight-recorder program based on lttng infrastructure.
> >>>>>>
> >>>>> Hrm, I'm wondering if these are events we are interested to trace or if
> >>>>> you plan to use these tracepoints as hooks into the kernel to connect
> >>>>> the tracer infrastructure to it ?
> >>>> Hello, Mathieu
> >>>>
> >>>> IMHO, both.
> >>>>
> >>>> As a programmer who want to build  flight-recorder based on lttng infrastructure,
> >>>> he can:
> >>>> 1: use lttng trace, and get lttng's trace datas from kernel-dump file.
> >>>> or
> >>>> 2: use lttng's tracepoint, and record events himself.
> >>>>
> >>>> But as a lttng's programmer, we can make both way possible.
> >>>>
> >>>> What is your opinion?
> >>>>
> >>> Yes, I think having both is good. So we could add, separately :
> >>>
> >>> A hook in panic and kexec using include/linux/notifier.h so mechanisms
> >>> other than tracers can connect their hook to it.
> >>>
> >>> Also add a tracepoint so tracers can use this as an event source.
> >>>
> >>> I would do both in separate patches though, because they have different
> >>> purposes.
> >> Hello, Mathieu
> >>
> >> Are you means you will do both in next version of lttng?
> >> Thanks!
> >>
> > 
> > Hi Zhaolei,
> > 
> > I won't create the patches myself because I don't see it as a priority
> > (Linus said he would refuse any instrumentation patch before we get the
> > data output mechanism into the kernel), but if someone provides patches
> 
> Hi, Mathieu,
> 
> You *forgot* one thing: we are lttng *users*, not only developers.
> I don't think it's good that you just heard the God only.
> 
> lttng is used by her users at the end. User's need is one of the
> first class things to concern.
> 
> > to add notifier feature to kexec and panic so we can plug LTTng into
> > them to extract traces from a crashed kernel, I would be very interested
> > to add this. OTOH, about the tracepoints, I am not convinced they are
> > necessary for now, because we already instrument printk which logs some
> > information on panic(). Maybe kexec would be better suited for
> > instrumentation.
> 
> We need to know the time and other information that panic happened.
> And output message is integrated in lttng with other messages.
> I don't think it's bad idea which we use for a long time.
> 
> And this is a *key message*, event should be generated efficient/elegant.
> 
> Sorry for participated in this discuss with bad manners.
> 

No no, that's ok :) Well, if the panic event is useful, I have nothing
against it. I just think that if the tracer starts hooking in some parts
of the kernel to do something else than just logging events (e.g.
triggering a full dump), then we should think about using the standard
notifiers interface (mabe in addition to tracepoints).

And about the "I won't create the patches myself", it's just a matter of
priority. I focus on mainline integration currently, but I have nothing
against integrating work done by others in the LTTng project. I hope
this clarifies my point of view a bit.

Mathieu

> Thanks, Lai.
> 
> > 
> > Also, it would be good to provide the LTTng probes for the tracepoints
> > you add in a separate patch within the same patchset
> > (ltt/probes/*-trace.c).
> > 
> > Thanks,
> > 
> > Mathieu
> > 
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68