Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, BartÅomiej ZimoÅ wrote:
> Dnia 3 stycznia 2010 0:29 "Rafael J. Wysocki" <rjw@xxxxxxx> napisaÅ(a):
> > > Thanks for Your answare.
> > > Some points of my idea:
> > > - don't think everyone want to use pm-utils (didn't say it is bad)
> > 
> > That certainly is true, but I think these people won't have a problem setting
> > up their suspend scripts to trigger the notification anyway. :-)
> > 
> 
> But it means almoust always create dbus interface and send message by script.

Of course you don't need to do that.  For example, you can use a UNIX domain
socket for sending the notification from one user space process (a power
manager) to another one (application wanting to be notified) and the
confirmation that's safe to suspend the other way around.  Generally, arbitrary
message-passing interface between two processes would be fine IMO.

...
> > To put it in a different way, you apparently want the kernel to notify the user
> > space of an event originating from the user space and my question is why not
> > to set up the user space to generate the notification without relying on the
> > kernel to do that.
> 
> Because now kernel know better what is going on.

That's because it's just been told by the user space about that.

Basically, you want something like this to happen:

process A ->(suspend) kernel
kernel ->(suspending) process B

where the kernel won't wait for process B to do whatever it has to do before
suspending.  In my opinion it'd be better to do something like this

process A ->(suspending) process B
process B ->(ack) process A
process A ->(suspend) kernel

... 
> > At least, that requires some more discussion, so please tell us why you need
> > the kernel to notify the user space about suspend/hibernation.  IOW, what's the
> > final purpose of this?  [Added some CCs.]
> 
> Yes, it is only first step.
> Have created different point of view, not all linux boxes are desktops/laptops.
> What about embedeed solutions?
> Why app must implement all other to know about resume/suspend?
> Why not open file and know this easily?

And why not to open a socket?

Really, what I think you want is a standard way of notifying applications that
suspend or hibernation is going to happen, but you don't need the kernel to
take part in that directly.

Putting things into the kernel is not the only way to avoid overheads IMO.

... 
> First of all i want to start discussion about this topic and looks like started :)
> 
> So what was in my mind? There are lots of small devices today with linux.
> Lots of them has got unstandardized suspend/resume detection.

OK, so we need a standard here.  I can't agree more.  However, does that mean
the kernel has to be directly involved in that?  If it does, then why exactly?

> It could be too much info exposed from kernel by this module/propose i understand
> for program info about pm_post_resume event could be anought.
> 
> We have now 3types of suspend implementation and 1 kernel API inside.
> App typicaly need just 2-3 event types - suspending, resumming, idle.
> I dont want to slow down kernel suspend, block or something, just perform 
> some actions in apps - typicaly try to reconnect.
> It could be new kernel standard to easy adept some actions.
> 
> Why not pm-utils connect to such module and gather data?
> Then It could work as hal service.
> But hook on kernel like /sbin/init but for suspend and resume, looks like other solution.
> IOW sending event to kernel to perform action and launch userspace once 
> more just before pm-event chain ... check return_val, sounds like other 
> solution/ other kind of module.

Again, you don't need a kernel module for that.  Moreover, using a kernel
module for that is actually inconvenient.

> What about this discusion:
> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html

Well, it would be nice if the desktop people sent CCs of such discussions to
linux-pm.  Talking about the kernel without involving people who actually work
on it is not exactly productive IMO.

Rafael
--
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/