[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0fa9e4e7-1247-4c82-8c0b-fa65b7fbb56d@infradead.org>
Date: Fri, 25 Jul 2025 20:36:18 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Eugen Hristev <eugen.hristev@...aro.org>, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-arch@...r.kernel.org,
linux-mm@...ck.org, tglx@...utronix.de, andersson@...nel.org,
pmladek@...e.com
Cc: linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org,
corbet@....net, mojha@....qualcomm.com, rostedt@...dmis.org,
jonechou@...gle.com, tudor.ambarus@...aro.org
Subject: Re: [RFC][PATCH v2 01/29] kmemdump: introduce kmemdump
Hi,
On 7/24/25 6:54 AM, Eugen Hristev wrote:
> diff --git a/drivers/debug/Kconfig b/drivers/debug/Kconfig
> new file mode 100644
> index 000000000000..b86585c5d621
> --- /dev/null
> +++ b/drivers/debug/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0
> +menu "Generic Debug Options"
> +
> +config KMEMDUMP
> + bool "Allow the kernel to register memory regions for dumping purpose"
> + help
> + Kmemdump mechanism allows any driver to register a specific memory
> + area for later dumping purpose, depending on the functionality
> + of the attached backend. The backend would interface any hardware
> + mechanism that will allow dumping to happen regardless of the
> + state of the kernel (running, frozen, crashed, or any particular
> + state).
> +
> + Note that modules using this feature must be rebuilt if option
> + changes.
It seems to me that this (all of the KMEMDUMP Kconfig options) could live in
mm/Kconfig.debug instead of creating a new subdir for it.
--
~Randy
Powered by blists - more mailing lists