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
| ||
|
Date: Thu, 06 Jan 2011 18:30:20 -0800 From: John Stultz <john.stultz@...aro.org> To: Arve Hjønnevåg <arve@...roid.com> Cc: linux-kernel@...r.kernel.org, Brian Swetland <swetland@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, Alessandro Zummo <a.zummo@...ertech.it>, rjw@...k.pl Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers On Thu, 2011-01-06 at 16:58 -0800, Arve Hjønnevåg wrote: > 2011/1/6 John Stultz <john.stultz@...aro.org>: > > So otherwise, do you see any reason why android might not be able to > > adapt this code to replace the android alarm timers? > > > > The user-space interface does not look appealing, but I don't see any > reason why the in-kernel interface(s) cannot be shared. Our user-space > code has a single thread that waits for alarms to trigger, while the > alarms can be modified from any thread. So its something like nanosleep(), only other threads can extend or shorten the sleep time? Could you explain some of the rational for such an interface, so I can better understand the need? > As far as I can tell, using > the posix interface would either require a thread per alarm (up to 5) > or using signals. Both make the user-space code more complicated, and Yea, it probably would need signals, but I'd have to grok the use case a little better. And its possible it would complicate the user-space code some, but on the other hand, it would be using a more standard kernel interface. The other option is extending the posix interface to try to better match the need. > it is not clear if either of them provide a clear hand-off between > where the kernel needs to block suspend because the alarm has not been > delivered to user-space and where user-space needs to block suspend > because it is handling the alarm. Indeed. I'm still looking into the pm_wake details to see the limitations there. Some method of inheriting a stay_awake seems to be needed, but sounds pretty ugly. Alternatively we may need some method or callback to the kernel to detect that a signal has been handled by userland (allowing the pm_relax to occur). Rafael: Any thoughts here? thanks -john -- 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