在 2017/2/14 10:35, Nicholas Piggin 写道:
On Mon, 13 Feb 2017 19:00:42 -0200
"Guilherme G. Piccoli" <gpicc...@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 <gpicc...@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
