Re: [Xen-devel] [PATCH v3 1/4] xen: use common output function in debugtrace

[Juergen Gross <jgross@xxxxxxxx>]

On 03.09.19 14:09, Jan Beulich wrote:
> On 03.09.2019 13:58, Juergen Gross wrote:
> > On 03.09.19 13:47, Jan Beulich wrote:
> > > On 03.09.2019 12:22, Juergen Gross wrote:
> > > > On 03.09.19 12:00, Jan Beulich wrote:
> > > > > On 28.08.2019 10:00, Juergen Gross wrote:
> > > > > > Today dumping the debugtrace buffers is done via sercon_puts(), while
> > > > > > direct printing of trace entries (after toggling output to the console)
> > > > > > is using serial_puts().
> > > > > >
> > > > > > Use sercon_puts() in both cases, as the difference between both is not
> > > > > > really making sense.
> > > > > No matter that I like this change, I'm not convinced it's correct:
> > > > > There are two differences between the functions, neither of which
> > > > > I could qualify as "not really making sense": Why is it obvious
> > > > > that it makes no sense for the debugtrace output to bypass one or
> > > > > both of serial_steal_fn() and pv_console_puts()? If you're
> > > > > convinced of this, please provide the "why"-s behind the sentence
> > > > > above.
> > > > Okay, I'll use:
> > > >
> > > > Use sercon_puts() in both cases, to be consistent between dumping the
> > > > buffer when switching debugtrace to console output and when printing
> > > > a debugtrace entry directly to console.
> > > Well, this is better as an explanation indeed, but it still doesn't
> > > make clear whether it wasn't in fact wanted for there to be a
> > > difference in where output gets sent. I may believe that bypassing
> > > pv_console_puts() wasn't intended, but the steal function bypass
> > > had been there in 3.2 already, so may well have been on purpose.
> > There are two users of console_steal():
> >
> > suspend handling - I believe it is a good idea to not use the serial
> > interface while it is potentially uninitialized.
> I agree here.
>
> > gdb support - Why should that be special? Not treating the output data
> > appropriate to the attached debugger will be worse than encapsulating
> > it in a way the debugger can handle.
> I'm not sure here - it may well have been intentional to avoid
> cluttering the debugger console.
But won't using serial_puts() clutter the debugger console? "normal"
printk() output seem to be handled in a special way with gdb active,
while just using serial_puts() with attached gdb is looking at least
suspicious to me. There seems to be a special format, e.g. text output
of the hypervisor is prepended with 'O' and the data is sent in hex
representation. I can't imagine just sending some ASCII text is the
desired approach for debugtrace output.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel