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

[Juergen Gross <jgross@xxxxxxxx>]

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.

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.


Juergen

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