linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100602221309.6da754e7@schatten.dmk.lab>
Date:	Wed, 2 Jun 2010 22:13:09 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> > 2010/6/2 Peter Zijlstra <peterz@...radead.org>:
> > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> > >> No I want you to stop confusing low power idle modes with suspend.
> > >
> > > I think it is you who is confused. For power management purposes suspend
> > > is nothing more but a deep idle state.
> > 
> > No, idle is transparent, suspend is not.
> 
> Which is where the problem is, it should be.
> 
> > Why would I add suspend blockers to the code I want to prevent running?
> 
> Because what you want might not be what others want. Suppose you're fine
> with your torrent client/irc client/etc.. to loose their network
> connection when you're not behind your desktop so you don't add suspend
> blockers there.
> 
> Me, I'd be ready to administer physical violence if either of those lost
> their connections when I wasn't around to keep the screen-saver from
> kicking in.

Do you switch your pc on and off manually? Sometimes? Really?
(if not, you are probably a kernel hacker *g*) 

I assume, in general, there are only a few reasons to shut down a
machine: 

1. One has to do maintainance on the hardware or somehow needs to
interrupt the power supply.

2. One wants to save power. 

3. One wants to go easy on the hardware. 

4. ...?

Obviously, for reason 1 we need to maintain the shutdown-paths
indefinitely.  

But the rest are usecases that are similar to the suspend-blocker
usecases. You know that you are not using the machine and going
through the pain to shut down your machine. You have to do it manually.
Why? 

> This leads to having to sprinkle magic dust (and lots of config options)
> all over userspace. Something that gets esp interesting with only a
> boolean interface.

A userspace daemon could keep track of what applications can be
ignored. The wordprocessor probably should not keep the system busy. As
well as a running firefox. 

It is a hard problem. But we have _no way of deciding any of this in
the kernel_!


> 
> In the example above, having an active net connection would prevent my
> desktop from suspending, but what if another platform can maintain net
> connections while suspended? Do we then end up with arch specific code
> in the net-stack? I'm sure DaveM would love that.
> 
If it is driver knowledge, then it goes into the driver.
If it is platform knowledge, then it goes into the platform code.
I think that is a clear requirement to keeping sanity. 

The problem is there independently of suspend blockers. If the system
can suspend with network up, then you shure as hell want to suspend
even if the network is up. So it would actually be a reason for any
kind of "suspend blockers" scheme. Wouldn't it?

Cheers,
Flo
--
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/