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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

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