Message-Id: <201001030029.22449.rjw@sisk.pl>
Date:	Sun, 3 Jan 2010 00:29:22 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Bartłomiej Zimoń <uzi18@...pl>
Cc:	Andy Walls <awalls@...ix.net>,
	Daniel Borkmann <danborkmann@...glemail.com>,
	linux-kernel@...r.kernel.org,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [suspend/resume] Re: userspace notification from module

On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
> 
> Dnia 2 stycznia 2010 22:01 "Rafael J. Wysocki" <rjw@...k.pl> napisał(a):
> 
> > On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 2 stycznia 2010 16:56 	Daniel Borkmann <danborkmann@...glemail.com> napisał(a):
> > > > Hi Andy,
> > > > 
> > > > 2010/1/2 Andy Walls <awalls@...ix.net>:
> > > > > Why not:
> > > > >
> > > > > a. write a module that implements a device node that supports poll(),
> > > > > and
> > > > >
> > > > > b. have a user space process select() on the fd for read or exception
> > > > > notification
> > > > >
> > > > > ?
> > > > 
> > > > This is, of course, another possible solution that is more "cleaner"
> > > > than the one with the signals.
> > > > Then, your userspace program would have another thread polling for the
> > > > device node. Question is which timeout would be appropriate to be "CPU
> > > > friendly" and to keep notification latency short?
> > > > 
> > > 
> > > Just need as fast as possible solution and on the other hand acceptable for kernel sources.
> > > Usually programs needs just to disconnect something or set one flag.
> > > Even if program will have no time for this it could be enough just to send this precious info.
> > 
> > Perhaps I don't understand correctly what you're trying to achieve, but at the
> > moment suspend is always started from user space, this way or another, and on
> > the majority (all?) of the modern distros pm-utils is involved in that.
> > So, why don't you provide a pm-utils hook for your process (like, for example,
> > NetworkManager)?
> > 
> 
> 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. :-)

Point is, suspend hooks are used anyway by almost everyone (due to graphics,
networking, faulty drivers), so I think you could just use this mechanism, be it
pm-utils or something else.

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.

> - this code is standard for all implementation of suspend/hibernate/resume

I guess you mean the existing kernel-side suspend/hibernate code.

Sure, it is, but your module is going to export the kernel's internal interface
outside the kernel, turning it into a real API and that is a _big_ _deal_.  The
reason why it is a big deal is that while we often change the kernel's internal
interfaces, we don't change APIs.  Once created, an API (I mean a real
userland-kernel interface) is very difficult to change, because that most often
leads to regressions which are quite nasty from the user's point of view.

So, basically, you want us to declare that the kernel's internal
suspend/hibernate notification mechanism won't change in the future, which is
not something I'm going to do at this point.  Moreover, it hasn't been designed
as an API and I don't think it's really suitable for this purpose.

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.]

> - it is small
> - it have less overhead, dont need dbus and all rest services.

That could have been a good argument if those services had not been used
already, but that's not the case.

> - could be even used partialy by pm-utils
> - it is perfect just to notify about event

OK, but why exactly do _you_ need that to happen?

There's one important drawback of making the kernel generate the notification.
Namely, even if your userspace task is notified by the kernel of a PM event,
that doesn't mean it'll have the time to act upon that, because the kernel will
attempt to freeze it right after the notification has been sent.  This means
you'd need a way to make the kernel wait for your user space process to finish
it's job before continuing the suspend/hibernate process.  Otherwise it's not
going to be very useful.

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

Powered by blists - more mailing lists