On Thursday 27 May 2010, Alan Stern wrote: > On Wed, 26 May 2010, Rafael J. Wysocki wrote: > > > On Wednesday 26 May 2010, Peter Zijlstra wrote: > > > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote: > > > > +To create a suspend blocker from user space, open the suspend_blocker > > > > special > > > > +device file: > > > > + > > > > + fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC); > > > > + > > > > +then optionally call: > > > > + > > > > + ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name); > > > > + > > > > +To activate the suspend blocker call: > > > > + > > > > + ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK); > > > > + > > > > +To deactivate it call: > > > > + > > > > + ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK); > > > > + > > > > +To destroy the suspend blocker, close the device: > > > > + > > > > + close(fd); > > > > > > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep > > > the SET_NAME thing if you really care. > > > > SET_NAME wouldn't serve any purpose in that case. > > > > This whole thing is related to the statistics part, which Arve says is > > essential to him. He wants to collect statistics for each suspend blocker > > activated and deactivated so that he can tell who's causing problems by > > blocking suspend too often. The name also is a part of this. > > > > In fact, without the statistics part the whole thing might be implemented > > as a single reference counter such that suspend would happen when it went down > > to zero. > > There's also Arve's other main point: These suspend blockers tend to > get used quite a lot. Opening and closing a file each time has much > higher overhead than a simple ioctl. > > All these topics have been covered earlier in this discussion. Peter > should go back and read the emails in the linux-pm archive. Yeah. Although with a reference counter the special device file won't be necessary. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html