On Mon, May 02, 2011 at 02:43:34PM +0200, Jan Kiszka wrote:
> 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?
>
My original patch allowed logging of qxl debug output to a chardev of my
choice. I'm
trying to achieve the same thing using the tracing framework. The way is I
think to
add a DeviceState.debug_chardev that is settable when the device is created (no
state
in the tracing framework) and use that from the stderr framework.
This seems to be a little bit difficult with the current stderr backend
implementation
which never has any handle to a DeviceState. I'll have to fix that, and then it
can
be something like:
static inline void trace_$name(DeviceState *dev, $args)
{
if (!dev || !dev->debug_chardev) {
fprintf(stderr, "$name $fmt\n" $argnames);
else {
qemu_chr_print("$name $fmt\n" $argnames);
}
}
> > 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
