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
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?
4. the equivalent of setting a loglevel is?
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
2.b augment the simpletrace backend in the same way.
Any comments?
Alon
