[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfc5f964d8dadd6378f2da5b3b6ef4bc9fb847c2.camel@sipsolutions.net>
Date: Wed, 10 Aug 2022 18:03:37 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Manish Mandlik <mmandlik@...gle.com>,
Arend van Spriel <aspriel@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
marcel@...tmann.org, luiz.dentz@...il.com
Cc: Dan Williams <dan.j.williams@...el.com>,
Jason Gunthorpe <jgg@...pe.ca>,
linux-bluetooth@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
"Rafael J . Wysocki" <rafael@...nel.org>,
chromeos-bluetooth-upstreaming@...omium.org,
Won Chung <wonchung@...gle.com>,
Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/5] sysfs: Add attribute info for
/sys/devices/.../coredump_disabled
On Wed, 2022-08-10 at 09:00 -0700, Manish Mandlik wrote:
> This patch adds the specification for /sys/devices/.../coredump_disabled
> attribute which allows the userspace to enable/disable devcoredump for a
> particular device and drivers can use it to enable/disable functionality
> accordingly. It is available when the CONFIG_DEV_COREDUMP is enabled and
> driver has implemented the .coredump() callback.
>
It would be nice to say _why_? What problem does this solve? You could
just create the dump and discard it, instead, for example?
johannes
Powered by blists - more mailing lists