On Wednesday, 4. March 2009, Pavel Machek wrote: > Hi! > > > > > here is network packets. You just don't want to open/close a fd for > > > > every network packet that you process. Neither for serial data, > > > > bluetooth packets, ... > > > > > > You mix userland and kernel users. > > > > No. I don't. > > The idea of wake locks was to hand locks over from a driver's interrupt > > all the way to userspace. > > This is done in an interlocked way to ensure that the device does not > > suspend from the time of interrupt until userspace has handled the event > > that caused the interrupt (e.g. A modem sending "RING" on the serial > > line). > > Basically, in a timerless wake lock implementation userspace has to take > > a wake lock every time select returns. > > Well... in case it is really performance critical, we may want new > syscalls. > > Actually, given how deep change of semantics this is, new syscalls may > be good idea. > > Or better yet eliminate polling from userspace apps and just avoid > suspending whenever userspace is running (like sleepy patches do). > Pavel I don't know the details of sleepy linux so I'd appreciate if someone can eluminate if the following scenarios could be handled efficiently with sleepy linux: 1) You wake up through RTC, read the battery, update the color of your fancy 'battery good' LED and go back to sleep imediately. The real work takes milliseconds. 2) You send a request to the internet and go idle by selecting for an answer. You probably don't want to go to sleep as you know, the answer will be there shortly. Uli -- ------- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Head of Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing director: Hans-Peter Constien _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
