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.kis...@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
