[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.