2010/4/22 Matt Helsley <matthltc@xxxxxxxxxx>:
...
> On Thu, Apr 22, 2010 at 06:08:51PM -0700, Arve Hjønnevåg wrote:
>> +To create a suspend_blocker from user-space, open the suspend_blocker device:
>> + fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
>> +then call:
>> + ioctl(fd, SUSPEND_BLOCKER_IOCTL_INIT(strlen(name)), name);
>
> Why not initialize the user suspend blocker struct by default and then
> allow each BLOCK to specify the name? Also, my guess is it's not
> really a name so much as a description of why we're blocking suspend,
> right?
>
There are stats tracked as long as the suspend blocker exists.
Specifying a new name every time you block suspend would make this
less useful.
> Should the kernel reject empty strings or strings composed only of
> "non-printing" characters?
>
Is there an existing function that check if a sting is "unsafe". If
so, I can add a call to this.
>> +
>> +To activate a suspend_blocker call:
>> + ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
>> +
>> +To unblock call:
>> + ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
>
> lsof will show which tasks hold the device open but not which ones
> are blocking suspend. If merely keeping the device open corresponded to
> blocking suspend then this would be obvious and no ioctls would be
> necessary -- just write() the name/description.
We track more information about suspend blockers than this.
>
> Do you block/unblock often enough that frequent open/close of the device are
> a problem?
Yes.
...
>> +
>> +static DEFINE_MUTEX(ioctl_lock);
>
> nit: Usually locks protect data -- not functions.
>
> Couldn't this be part of the user_suspend_blocker struct? That would allow
> the description/name to change as described above.
It mainly protects the allocation of that struct, so no. Allocating a
separate struct in open would work, but does not seem worth it at the
moment.
>
>> +
>> +struct user_suspend_blocker {
>> + struct suspend_blocker blocker;
>> + char name[0];
>> +};
>
> <snip>
>
> Cheers,
> -Matt Helsley
>
--
Arve Hjønnevåg
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
