Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[David Zeuthen <davidz-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

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



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm