Date: Fri, 18 Sep 2015 22:31:50 +0200 From: Dan Lukes <dan@obluda.cz> To: Colin Percival <cperciva@freebsd.org>, Ian Smith <smithi@nimnet.asn.au> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: disabling sleep when shutting down Message-ID: <55FC74B6.4050601@obluda.cz> In-Reply-To: <55FB4B4F.2080700@freebsd.org> References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> <55FB4B4F.2080700@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Colin Percival wrote: > The example of a system which can usefully suspend but doesn't have enough > battery life left to allow tit to complete a normal shutdown seems a bit > implausible It's valid for in-kernel portion of shutdown only. But you wish to disable suspend even during userland part of shutdown. Such part is generic shell script and even worse, it include third party scripts. We can tell nothing generic about it. Of course, same apply to suspend as well. Thus is plausible that suspend may take just few seconds, but shutdown take substantially longer. But it's another day now, few hours of sleeping and your idea no longer sound as unacceptable to me as yesterday. As long as default system behavior will remain the same, I have nothing against a tool/method/way that will allow user to block S3 state anytime, including the userland portion of shutdown. It's up to system administrator to turn on such feature whenever he feel it helpful. Suspend triggered by LID I recognize special case - it's easy to evaluate consequences in full, thus I consider acceptable modification of the default system behavior. Just personal opinion ... Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55FC74B6.4050601>