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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.09.2019 14:22, Juergen Gross wrote:
> 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.

Oh, did I get it backwards, I'm sorry. Yes, I agree. With the slightly
adjusted description
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan

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