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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
