Re: [Qemu-devel] debug logging

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-05-02 13:50, Alon Levy wrote:
> On Mon, May 02, 2011 at 01:00:01PM +0200, Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> On 2011-05-02 12:33, Alon Levy wrote:
>>>> On Mon, May 02, 2011 at 12:25:30PM +0200, Gerd Hoffmann wrote:
>>>>>   Hi,
>>>>>
>>>>>> dbg_print takes care of making it standard to have a loglevel and prefix, sounds
>>>>>> good, but I'd still like to know if it is acceptable to also redirect with -debug,
>>>>>> I guess reusing the DeviceState then, instead of my added struct, so just letting
>>>>>> DeviceState.debug_chardev == NULL by default, and settable with
>>>>>> -debug<devname>,id=<chardev_id>
>>>>>
>>>>> Making dbg_print use DeviceState.debug_chardev (if present, stderr
>>>>> otherwise) looks sane to me.  Buf I'd use standard properties then
>>>>> to set it instead of a separate -debug switch, i.e.
>>>>>
>>>>>   -chardev file,id=messages,path=... \
>>>>>   -device foo,dbg=1,dbglog=messages
>>>>>
>>>>
>>>> Sounds good. I'll try to make it so.
>>>
>>> We have a tracing infrastructure for such use cases today. Better invest
>>> in adding missing features there.
>>
>> Start with docs/tracing.txt
> 
> ok, I see that the file starts by saying it is meant to be used for debugging as
> well. Am I correct in the following?
> 1. to change tracing backends requires a recompile

Right. I mostly work with stderr backend as it can be redirected
wherever you want it (console, file, ftrace trace_marker).

> 2. can't have two tracing backends at the same time (i.e. either everything goes
> to stdout or everything is visible via systemtap etc.)
> 3. quoting:
>          Do not pass in string arguments.
>    how does that help debugging then?

This needs to be fixed, the infrastructure should be able to record
fixed sized strings (not kilobytes, but 32 bytes or so).

> 4. the equivalent of setting a loglevel is?

Right now either the use of systemtap or ust which allow per-tracepoint
enabling/disabling or enable simpletrace and use the trace-event monitor
command. On top you need local grouping of the tracepoints.

At least the latter needs fixing so that the developer of some module
can tag tracepoints in-tree. But I also think we should be tracepoint
control a generic feature, independent of the tracer backend as far as
possible (ust and systemtap likely provide interfaces to forward control
commands).

> 
> If I want to achieve my original intend, namely easily changing the target of specific
> qxl debug statements from stderr to a separate file, to view at runtime, I will need to:
> 1. turn all of them to trace calls
> 2. do one of:
>  2.a turn the stderr backend into a debug_chardev backend, defaulting to stderr
>  (this sounds simplest to me) and add this option

You should avoid using too much of qemu's infrastructure in the tracer,
specifically if holds some state. Or am I misunderstanding your plans?

>  2.b augment the simpletrace backend in the same way.
> 
> Any comments?
> 
> Alon

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux