Re: Generic events for wake up from S1-S4

From: Luis R. Rodriguez
Date: Mon Jul 20 2009 - 12:27:43 EST


On Sat, Jul 18, 2009 at 4:56 PM, Henrique de Moraes
Holschuh<hmh@xxxxxxxxxx> wrote:
> On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
>> Hm yeah, but I doubt someone will do that, generally we'd get one wake
>> up event. Can't we just report the first one and ignore the rest?
>
> Well, I'd say keeping it simple is best, here. ÂWhat if you ignore the more
> interesting wakeup events by chance (and it is really up to userspace to
> know what it considers interesting...)? ÂIMHO, just issue as many
> notifications as needed, let userspace filter it if it wants.
>
> But if you guys are talking about something really generic, shouldn't it
> also provide the important "why" along with the "who"?
>
> Even for the most common cases, the "why" is useful: userspace may well want
> to run special routines when it wakes up because of WoL and WoW (instead of
> a key press, lid open or mouse movement...).
>
> When you factor in wakeups caused by platform alarms, well, the "why"
> becomes even more interesting.

We'd need a generic interface for keeping track of all possible
wake-up-triggers. Should be easy with udev events.

>> > What about simply reporting "wake event happened on this device" and
>> > doing that for all the devices?
>>
>> That's fine too. Just think it would be nice to be more specific if possible.
>
> A generic way for a device (of any sort, not just network devices!) to
> report that they just issued a system wakeup message, as well as the reason
> it did that seems like a good way to do it to me.

This should be easy to do via udev events.

How about an generic platform registered, and udev events issues for
wake-up-triggers, and also for wake-up-events, and leave all the
sorting out to userspace? All we'd need in-kernel would be the trigger
registration and event trigger notifications.

Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/