[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] debug logging
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] debug logging |
Date: |
Mon, 02 May 2011 14:43:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-05-02 13:50, Alon Levy wrote:
> On Mon, May 02, 2011 at 01:00:01PM +0200, Markus Armbruster wrote:
>> Jan Kiszka <address@hidden> 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
- [Qemu-devel] debug logging (was: Re: [PATCHv2 3/4] qxl: add debug_cs and cmdlog_cs), Gerd Hoffmann, 2011/05/02
- Re: [Qemu-devel] debug logging (was: Re: [PATCHv2 3/4] qxl: add debug_cs and cmdlog_cs), Alon Levy, 2011/05/02
- Re: [Qemu-devel] debug logging, Gerd Hoffmann, 2011/05/02
- Re: [Qemu-devel] debug logging, Alon Levy, 2011/05/02
- Re: [Qemu-devel] debug logging, Jan Kiszka, 2011/05/02
- Re: [Qemu-devel] debug logging, Markus Armbruster, 2011/05/02
- Re: [Qemu-devel] debug logging, Alon Levy, 2011/05/02
- Re: [Qemu-devel] debug logging,
Jan Kiszka <=
- Re: [Qemu-devel] debug logging, Alon Levy, 2011/05/02
- Re: [Qemu-devel] debug logging, Paolo Bonzini, 2011/05/02