| 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
| ||
|
Message-ID: <4BE386D1.2050608@cnu.edu> Date: Thu, 06 May 2010 23:19:45 -0400 From: James Kosin <james.kosin.04@....edu> To: Arve Hjønnevåg <arve@...roid.com> CC: linux-kernel@...r.kernel.org Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api. On 5/6/2010 11:10 PM, Arve Hjønnevåg wrote: > 2010/5/6 James Kosin <james.kosin.04@....edu>: > >> On 5/6/2010 10:53 PM, Arve Hjønnevåg wrote: >> >>> On Thu, May 6, 2010 at 7:41 PM, James Kosin <james.kosin.04@....edu> wrote: >>> >>> >>>> On 5/5/2010 8:10 PM, Tony Lindgren wrote: >>>> >>>> >>>>> * Brian Swetland <swetland@...gle.com> [100505 16:51]: >>>>> >>>>> >>>>>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@...mide.com> wrote: >>>>>> >>>>>> >>>>>>> * Brian Swetland <swetland@...gle.com> [100505 14:34]: >>>>>>> >>>>>>> >>>>>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@...land.harvard.edu> wrote: >>>>>>>> >>>>>>>> >>>> <<-- snip -->> >>>> >>>> >>>>>>>>> At no point does the user program have to communicate anything to the >>>>>>>>> modem driver, and at no point does it have to do anything out of the >>>>>>>>> ordinary except to enable and disable a suspend blocker. >>>>>>>>> >>>>>>>>> >>>>>>>> Exactly -- and you can use the same style of overlapping suspend >>>>>>>> blockers with other drivers than input, if the input interface is not >>>>>>>> suitable for the particular interaction. >>>>>>>> >>>>>>>> >>>>>>> Would the suspend blockers still be needed somewhere in the example >>>>>>> above? >>>>>>> >>>>>>> >>>>>> How often would we retry suspending? >>>>>> >>>>>> >>>>> Well based on some timer, the same way the screen blanks? Or five >>>>> seconds of no audio play? So if the suspend fails, then reset whatever >>>>> userspace suspend policy timers. >>>>> >>>>> >>>>> >>>> Tony, >>>> Wouldn't this be handled by the idle task, or task manager? >>>> >>>> When all tasks are suspended and not doing anything that should be the >>>> first clue that a real suspend cycle could be attempted. >>>> >>>> >>>> >>> One if the benefit we get from using suspend is that an unprivileged >>> app that does not have access to suspend blockers cannot prevent >>> suspend. You lose this advantage if you trigger suspend only from the >>> idle task. >>> >>> >>> >> If the process (privileged or unprivileged) doesn't want to suspend, why >> not just provide an interface to allow suspend to be turned off at the >> user level. This could block the suspend cycle in itself, and you >> shouldn't need fine grained off/on cycles. If an application really >> needs the system not to suspend then they (the user) should know the >> consequences and power requirements for such a task. >> >> I didn't say it had to be only from the idle task; but, that is the most >> logical place. If the other threads are not idle then they really >> require work and will most likely already have a bock on the suspend anyway. >> >> > I think you missed my point. Unprivileged processes should not be > allowed to prevent suspend. > > Ah, you want a way for the system to suspend (and enforce the suspend) when only unprivileged processes are the only thing running.... That would mean a lot of work defining the unprivileged (or privileged) processes, and properly suspending (or enforcing) when needed. Yuck. Sorry I commented then, this is really getting deep into what I love to do at work. -- 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