Re: [PATCH] powerpc/xmon: add debugfs entry for xmon

[Pan Xinhui <xinhui@linux.vnet.ibm.com>]

在 2017/2/14 10:35, Nicholas Piggin 写道:
> On Mon, 13 Feb 2017 19:00:42 -0200
> "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com> wrote:
>
>> Currently the xmon debugger is set only via kernel boot command-line.
>> It's disabled by default, and can be enabled with "xmon=on" on the
>> command-line. Also, xmon may be accessed via sysrq mechanism, but once
>> we enter xmon via sysrq,  it's  kept enabled until system is rebooted,
>> even if we exit the debugger. A kernel crash will then lead to xmon
>> instance, instead of triggering a kdump procedure (if configured), for
>> example.
>>
>> This patch introduces a debugfs entry for xmon, allowing user to query
>> its current state and change it if desired. Basically, the "xmon" file
>> to read from/write to is under the debugfs mount point, on powerpc
>> directory. Reading this file will provide the current state of the
>> debugger, one of the following: "on", "off", "early" or "nobt". Writing
>> one of these states to the file will take immediate effect on the debugger.
>>
>> Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>> ---
>> * I had this patch partially done for some time, and after a discussion
>> at the kernel slack channel latest week, I decided to rebase and fix
>> some remaining bugs. I'd change 'x' option to always disable the debugger,
>> since with this patch we can always re-enable xmon, but today I noticed
>> Pan's patch on the mailing list, so perhaps his approach of adding a flag
>> to 'x' option is preferable. I can change this in a V2, if requested.
>> Thanks in advance!
>
> xmon state changing after the first sysrq+x violates principle of least
> astonishment, so I think that should be fixed.
>
hi, Nick
yes, as long as xmon is disabled during boot, it should still be disabled after existing xmon.
My patch does not fix that as it need people add one more char 'z' following 'x'.
I will provide a new patch to fix that.

> Then the question is, is it worth making it runtime configurable with xmon
> command or debugfs tunables?
>
They are options for people to turn xmon features on or off. Maybe people needn't this.
However I am not a fan  of debugfs this time as I am used to using xmon cmds. :)

Hi, Guilherme
So in the end, my thought is that: 1) cmd x|X will exit xmon and keep xmon in the original state(indicated by var xmon_off).
2) Then add options to turn some features on/off. And debugfs maybe not fit for this. But I am also wondering at same time, are people needing this?

thanks
xinhui

> Thanks,
> Nick
>