linux-kernel - Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces

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]

Date:	Fri, 28 Oct 2011 19:26:27 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	NeilBrown <neilb@...e.de>,
	Linux PM list <linux-pm@...r.kernel.org>,
	mark gross <markgross@...gnar.org>,
	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Brian Swetland <swetland@...gle.com>, Greg KH <greg@...ah.com>
Subject: Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces

On Friday, October 28, 2011, Alan Stern wrote:
> On Fri, 28 Oct 2011, Rafael J. Wysocki wrote:
> 
> > > > Now, in the end, I think our approach makes more sense in a general 
> > > > setting.  The Android approach is okay for a restricted environment 
> > > > where you know beforehand exactly which devices will be wakeup-capable 
> > > > and which wakeup events will be monitored by userspace programs.  But 
> > > > for the whole range of Linux-based systems, the kernel can't rely on 
> > > > such information.
> > > 
> > > I think that is exactly right.  The Android code is understandable written
> > > to particularly suit the Android context and may not be generally applicable.
> > 
> > I'm not sure why the heck this makes any difference.  For now, there doesn't
> > seem to be no one else who needs that functionality.  If there were people
> > like that we'd see some concurrent approaches appearing, but for now it's only
> > us considering the alternatives _theoretically_.
> > 
> > Moreover, if somebody who needs similar functionality and for whom the Android
> > stuff is not sufficient appears in the future, I don't see why not to address
> > his needs _at_ _that_ _time_ instead of trying to anticipate them (which is
> > kind of useless anyway, because we have no idea what those needs may be).
> 
> You're missing the point.  There could easily be situations where the
> Android kernel will block suspend but a more general system should
> _not_ block it.  Behavior that is appropriate in an Android phone might
> not be appropriate in, say, a desktop system.
> 
> If we duplicate the Android functionality then people (who may or may
> not theoretically want it now) might find that they _don't_ want the
> new behavior.

Where is it said that is has to be mandatory?

> > > I think the Android folk understand this and don't insist on having exactly
> > > that code merged.  They just want the same functionality with the same
> > > efficiency without unnecessary change to user-space.
> > 
> > The whole problem is that the Android code is proven to work on lots and
> > lots of systems and whatever else we can come up with will not be.
> 
> But it seems likely that the Android code, which has been tested on 
> only one kind of system, will _not_ work correctly on other kinds of 
> systems.
> 
> Assuming we do go ahead and merge some form of the Android code, we
> must make sure that it won't have bad effects in situations where it's
> not needed or wanted.

Yes, that clearly is what we must do.

> This means more than configuring it away with Kconfig.  When it is present,
> there has to be a way to control its behavior in some detail.

I entirely agree.

Thanks,
Rafael
--
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/