[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070613222308.GA17266@suse.de>
Date: Thu, 14 Jun 2007 00:23:08 +0200
From: Stefan Seyfried <seife@...e.de>
To: Pavel Machek <pavel@....cz>
Cc: linux-kernel@...r.kernel.org,
suspend-devel List <suspend-devel@...ts.sourceforge.net>,
Frank Seidel <fseidel@...e.de>, akpm@...ux-foundation.org,
nigel@...el.suspend2.net, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH, 2nd try] make disable_console_suspend runtime configurable
On Thu, Jun 14, 2007 at 12:08:00AM +0200, Pavel Machek wrote:
> Hi!
>
> > I hate having to recompile the kernel, just to be able to debug suspend.
> > Remove CONFIG_DISABLE_CONSOLE_SUSPEND, replace it by a tunable in
> > /sys/power/disable_console_suspend.
>
> > Signed-off-by: Stefan Seyfried <seife@...e.de>
> > Signed-off-by: Frank Seidel <fseidel@...e.de>
>
> I wonder if there's a better name?
Suggest one.
> Or maybe this should not be /sys configurable, but just have value for
> each console "this console can work while suspended"?
>
> (serial can, vesafb can, netconsole can't)?
Go ahead, submit a patch. It won't be that trivial. And i wonder
if it is actually worth the hassle. This is a debugging facility.
> Exporting "crash-me" option to user does not seem that cool to me.
We have "echo c > /proc/sysrq-trigger" also.
This is a debugging option, and forcing users to recompile the kernel just
to debug suspend problems (not resume problems, the "it does not even go to
sleep" stuff is where this matters most) is IMO a bad idea.
We can also make this a boot parameter, i don't care, but i want to disable
console suspend without recompiling the kernel.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists