linux-kernel - Re: Power-managing devices that are not of interest at some point in time

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: <20140718192334.GA10631@google.com>
Date:	Fri, 18 Jul 2014 12:23:34 -0700
From:	Patrik Fimml <patrikf@...omium.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Patrik Fimml <patrikf@...omium.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Dmitry Torokhov <dtor@...gle.com>,
	Bastien Nocera <hadess@...ess.net>, linux-pm@...r.kernel.org,
	Benson Leung <bleung@...gle.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Power-managing devices that are not of interest at some point in
 time

On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> "Quiescing" is the wrong word.  "Quiescing a device" means stopping the
> device from doing anything, which isn't what you want.  You want to
> ignore any activity the device may generate and reduce the device's
> power consumption as much as possible.  A better word would be
> "deactivating".

Yeah, I agree that terminology is a bit tricky here, and we have some
words conveying a specific idea already ("suspend"). To me, deactivating
suggests a more permanent condition. FWIW, I've used "inhibit" in this
context before and think it captures the idea well, to add another
choice to the list.

> You mentioned that handles to the device would remain open.  So when 
> the user opens the lid again, the old handles would start functioning, 
> right?

That's the idea, yes, and I think this would be desirable for the input
device class at least.

> This has the disadvantage that the class device could not be
> unregistered, because doing so would invalidate the open handles.  
> Under such circumestances, how would a userspace video program know not
> to list a camera built into the lid among the possible video sources
> (an example given earlier in this discussion)?  The program would have
> to make an explicit test of the "deactivate" property -- it wouldn't
> automatically become aware that the camera wasn't available.
> 
> Would it sometimes be okay to unregister the class device and
> invalidate the old handles, forcing programs to open new handles when
> the lid is opened?  This would reduce the number of changes user 
> programs would need.

I guess we could potentially leave this for the device class to decide.

I'm not sure what the appropriate action for a video camera is anyway.
Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external
camera? I'm thinking along the lines of some application's settings
dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.

Of course, userspace could still decide simply not to
quiesce|deactivate|inhibit the device if that was desired.

Regards,
Patrik
--
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/