[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <494A37E9.5000009@vlnb.net>
Date: Thu, 18 Dec 2008 14:45:45 +0300
From: Vladislav Bolkhovitin <vst@...b.net>
To: Frédéric Weisbecker <fweisbec@...il.com>
CC: Steven Rostedt <srostedt@...hat.com>,
Sam Ravnborg <sam@...nborg.org>, linux-scsi@...r.kernel.org,
James Bottomley <James.Bottomley@...senpartnership.com>,
Andrew Morton <akpm@...ux-foundation.org>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
Mike Christie <michaelc@...wisc.edu>,
Jeff Garzik <jeff@...zik.org>,
Boaz Harrosh <bharrosh@...asas.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, scst-devel@...ts.sourceforge.net,
Bart Van Assche <bart.vanassche@...il.com>,
"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH][RFC 2/23]: SCST core
Frédéric Weisbecker, on 12/14/2008 03:35 AM wrote:
> 2008/12/13 Vladislav Bolkhovitin <vst@...b.net>:
>> Also (maybe I simply miss something) looks like ftrace doesn't trace exit
>> from functions, only entrance to them. Is it true? Is it possibly to log
>> exit from functions as well?
>
> That's true with 2.6.28, the function tracer traces on function entries only.
> But there is an add-on on ftrace which let one to trace on entry and
> on return, the function
> graph tracer. This tracer uses this facility to output a graph of
> function calls and measure
> the time elapsed during each function call.
> You can also register two custom handlers to do some things you need
> on entry and on return.
Word "graph" is quite confusing. We don't need any graphs, we need a
plain execution path tracing as in the attached example (this is what's
currently done).
>> All the above functionality is almost what we need. The only thing left,
>> which I forgot to mention, is possibility to log also functions return value
>> on exit. This is what TRACE_EXIT_RES() in SCST does. Is it possible to add
>> those?
>
> I want to add that on the function graph tracer. That can be done
> pretty easily. The only
> problem comes with the type of the return value. Would this tracer be
> supposed to always
> return a 64 bits value regardless of the real typ of the value? There
> would be some pointless bytes
> on most return values. I don't know how to proceed for this problem.
I think if tracer always returns machine word, as Ingo suggested, as
"%d(%x)" it would be more then sufficient. In the rest of 0.01% of cases
it wouldn't be hard to print a non-standard return value using
ftrace_printk() just before returning it.
>> And one more question. Is it possible to redirect ftrace tracing to serial
>> console or any other console (netconsole?)? It can be helpful to investigate
>> hard lockups in IRQ or with IRQs disabled.
>>
>> Thanks!
>> Vlad
>>
>
> I would find it useful too. I thought about something like using
> early_printk or something like
> that...I don't know. That would be good to redirect the output to the
> tty device of the user choice.
That would make ftrace a complete debug logging subsystem.
View attachment "exm" of type "text/plain" (4993 bytes)
Powered by blists - more mailing lists