On Fri, 2005-03-11 at 09:41 +0100, Pavel Machek wrote: > On Pá 11-03-05 00:28:55, David Zeuthen wrote: > > On Fri, 2005-03-11 at 00:07 +0100, Pavel Machek wrote: > > > > I was merely asking for an event when the system is resumed. > > > > > > > > I agree it doesn't make much sense for an event just before the system > > > > is suspended - if this is needed I believe we can orchestrate it > > > > completely from user space (things like making your email app > > > > synchronize etc. comes to mind). > > > > > > You can have event when the system is resumed. Just do it in userspace. > > > > > > > Maybe I'm reading the source wrong, but isn't it the case that some > > laptops using APM (my IBM thinkpad T41 with acpi=off for instance) > > suspends without user space interaction when the lid is closed, thus > > rendering it impossible to send the event from user space? > > > > One may even ask whether it's sound to assume that all architectures > > will be suspended via user space? > > Some machines will suspend without even telling operating system > anything. > > For APM case, yes some kind of notification makes sense (I thought we > were talking ACPI/swsusp here). > Oh, I thought the kernel was moving towards presenting user space with an abstract interface much like /sys/power/state; that would definitely be easier on user space (we don't have to add new code for every PM framework), but I do understand if you don't want to do this as it have negative consequences. But at least some form of feature parity across different PM frameworks would be nice (e.g. if you make APM resume send an event, do the same for ACPI and PMU) because in many ways user space do have to design for lowest common denominator when abstracting this. > > > . I'm *not* going to do that from kernel. But standartizing what needs > > > to be ran on resume is indeed good idea, and few lines in > > > Documentation/power/* are probably worth it. > > > > > > > There's a very practical problem of getting all distributions to > > actually do this. > > Where doing it kernel means we have to do it right.. > I understand that, yes. > > Another point is that user space may just use a timer and look at the > > wall clock to determine when a suspend happens, but that's hardly an > > elegant architecture. It does save some discussion, though, either way > > I'll be quiet now and leave you guys to do real work :-) > > Well, if you propose reasonable way to notify userspace, you can get > it at least for APM case... So do not drop quiet just now. I'm not a kernel hacker, sorry, my best bet would be using the kobject_uevent stuff (since that is used for other notifications) but I don't really grok all the locking and synchronization needed to do this right without races / deadlocks. I was just adding to this thread because Alan asked what user space would like to see :-) Cheers, David
