Re: [linux-pm] [suspend/resume] Re: userspace notification from module

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 6 stycznia 2010 0:05 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> Well, I think you have some specific issue with pm-utils, but you're not
> telling us what it is.  So, why exactly is pm-utils not suitable for your
> needs?
> 

Rafael to be honest it's more dbus specific. I'm talking about 
dbus as it is standard for system<->apps communication.

But please understand if we'll create kernel device with simple pm notification
It could be hooked by udev and next ... by DeviceKit-power/upower and after that
we have real standard. But to have this we must export "power" device - something 
like my proof-of-concept module. This could be realy good start.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Wednesday 06 January 2010, Bartłomiej Zimoń wrote:
> Dnia 6 stycznia 2010 0:05 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > Well, I think you have some specific issue with pm-utils, but you're not
> > telling us what it is.  So, why exactly is pm-utils not suitable for your
> > needs?
> > 
> 
> Rafael to be honest it's more dbus specific. I'm talking about 
> dbus as it is standard for system<->apps communication.

That was my impression. :-)

Well, I don't like dbus too, but ...

> But please understand if we'll create kernel device with simple pm notification
> It could be hooked by udev and next ... by DeviceKit-power/upower and after that
> we have real standard. But to have this we must export "power" device - something 
> like my proof-of-concept module. This could be realy good start.

... that doesn't make me think it should be sneakily replaced with "magic"
kernel modules or similar stuff.

As I already said many times in this thread before, please look for a solution
in the user space.

Rafael

Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 2 stycznia 2010 13:36 	Daniel Borkmann <llug.dan@googlemail.com> napisał(a):

> Hi Bartłomiej,
> 
> Bartłomiej Zimoń wrote:
> > Use inotify from userspace could be interesting for such data,
> > but looks like sysfs/procfs doesn't send signal about data changed in file or maybe i'm wrong?
> > 
> > If sysfs/procfs is wrong for that so must create device file, but here secound problem 
> > how to notify that file/buffer has new data?
> 
> Actually, the file content of a procfs file is volatile and generated on
> the fly, just have a look at some device drivers or at the API.
> 

As I fought. Reading now sources of some char drivers.

> Did you have a look at the netlink protocol for communication from
> kernel to userspace?
> 

Ok i will :)

I will explain more what i'm going to do.
The idea is simple. Kernel before suspend/resume sends notification to 
registered kernel objects. So i have written small module to register
there and want now pass these data to /dev/file. It is 1byte so not a big deal.

I'm searching now for notification about new byte in buffer, as it is almost 
clear for async: http://www.xml.com/ldd/chapter/book/ch05.html#t4
but for sync still haven't find.

It could be interesting for NetworkManager to hook on such event.

Looks like my post arrives 2nd time in lkml.

Thx for reply.

Best Regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team

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

[Rafael J. Wysocki]

On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> Dnia 4 stycznia 2010 0:30 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> 
> > On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > ...
> > > 
> > > It could be even UIO module but there are no pm events reachable there?
> > > 
> > > If it is not clean, we must extend pm-utils or write something new
> > > (with backends dbus, ipc, scripts, ...)
> > > But You see? We still have no information from kernel about events 
> > > (especialy resume) or maybe i dont see this ;/
> > 
> > They are available to the process that tells the kernel to suspend.
> > 
> > Namely, to tell the kernel to suspend to RAM, the process (call it a power
> > manager) needs to (for example) fprintf() "mem" to /sys/power/state.  As soon
> > as this happens, the kernel will start to freeze processes (except for the
> > power manager itself), so the power manager knows that everything should be
> > ready for the suspend before it writes to /sys/power/state.  It doesn't need
> > the kernel to tell it when the suspend is going to start, because it _knows_
> > that in advance.
> > 
> > Now, the fprintf() used to trigger the suspend will not return until the resume
> > is complete.  So, again, when the fprintf() returns, the power manager will know
> > that the resume has just finished (more precisely, the kernel side of it has
> > just finished).
> > 
> > There simply is no need for any special communication between the kernel and
> > the power manager.
> > 
> 
> Thx Rafael - now it clear to me.
> And what do You think about sending extra signals to processes?

I don't see a problem with this in principle, although I don't think signals
are very suitable for this particular purpose, because you need two-way
communication between the power manager and the processes it's going to
notify (because it has to wait for the processes to finish their preparations
and to tell it that they are ready).

For this purpose it's better to have a file descriptor you can block on (like a
socket or a pipe) while the other side is doing it's job.

Rafael

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

[Bartłomiej Zimoń]

Dnia 4 stycznia 2010 0:45 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> > Thx Rafael - now it clear to me.
> > And what do You think about sending extra signals to processes?
> 
> I don't see a problem with this in principle, although I don't think signals
> are very suitable for this particular purpose, because you need two-way
> communication between the power manager and the processes it's going to
> notify (because it has to wait for the processes to finish their preparations
> and to tell it that they are ready).
> 
> For this purpose it's better to have a file descriptor you can block on (like a
> socket or a pipe) while the other side is doing it's job.
> 

So let's create one in power/user.c or use /sys/power/state for this :)

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

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

[Rafael J. Wysocki]

On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> Dnia 4 stycznia 2010 0:45 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> > > Thx Rafael - now it clear to me.
> > > And what do You think about sending extra signals to processes?
> > 
> > I don't see a problem with this in principle, although I don't think signals
> > are very suitable for this particular purpose, because you need two-way
> > communication between the power manager and the processes it's going to
> > notify (because it has to wait for the processes to finish their preparations
> > and to tell it that they are ready).
> > 
> > For this purpose it's better to have a file descriptor you can block on (like a
> > socket or a pipe) while the other side is doing it's job.
> > 
> 
> So let's create one in power/user.c or use /sys/power/state for this :)

I don't see a good reason, really.

Rafael

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Anders Eriksson]

rjw@sisk.pl said:
>> > I don't see a problem with this in principle, although I don't think signals
>> > are very suitable for this particular purpose, because you need two-way
>> > communication between the power manager and the processes it's going to
>> > notify (because it has to wait for the processes to finish their preparations
>> > and to tell it that they are ready). 

Wouldn't there need to be dependecy tracking for the userspace processes? A 
process couldn't signal "done" until it know there's no more work to do, which 
requires all other processes to finish up first.

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > 
> > rjw@sisk.pl said:
> > >> > I don't see a problem with this in principle, although I don't think signals
> > >> > are very suitable for this particular purpose, because you need two-way
> > >> > communication between the power manager and the processes it's going to
> > >> > notify (because it has to wait for the processes to finish their preparations
> > >> > and to tell it that they are ready). 
> > 
> > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > process couldn't signal "done" until it know there's no more work to do, which 
> > requires all other processes to finish up first.
> > 
> 
> Not all processes will need pm notification.
> 
> Just in case, could this "power manager" be provided as userspace
> driver for kernel (for example compiled as UIO)?

I don't really understand why you want to do that in the kernel.  Is there
any particular reason why this cannot be done in the user space?

Rafael

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 5 stycznia 2010 22:23 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> > Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > > 
> > > rjw@sisk.pl said:
> > > >> > I don't see a problem with this in principle, although I don't think signals
> > > >> > are very suitable for this particular purpose, because you need two-way
> > > >> > communication between the power manager and the processes it's going to
> > > >> > notify (because it has to wait for the processes to finish their preparations
> > > >> > and to tell it that they are ready). 
> > > 
> > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > process couldn't signal "done" until it know there's no more work to do, which 
> > > requires all other processes to finish up first.
> > > 
> > 
> > Not all processes will need pm notification.
> > 
> > Just in case, could this "power manager" be provided as userspace
> > driver for kernel (for example compiled as UIO)?
> 
> I don't really understand why you want to do that in the kernel.  Is there
> any particular reason why this cannot be done in the user space?
> 

Problem is with notification from pm-utils. Dbus for session is only 
user session waid and it is almost imposible to send something 
from systembus or it needs lots of magic.

Even if i'll use pm-utils, must provide way to notify my app.
Looks like no standard way here, that's bad, every app has it's own?

I think this way - if kernel is processes manager and if it sends
"some unknown" signal to every process before kernel suspend so why
not send sepcific and known signal instread.

But now we have DeviceKit-power/upower whatever but it doesn't provide
this feature or something simmilar to relay on.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 22:23 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > > > 
> > > > rjw@sisk.pl said:
> > > > >> > I don't see a problem with this in principle, although I don't think signals
> > > > >> > are very suitable for this particular purpose, because you need two-way
> > > > >> > communication between the power manager and the processes it's going to
> > > > >> > notify (because it has to wait for the processes to finish their preparations
> > > > >> > and to tell it that they are ready). 
> > > > 
> > > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > > process couldn't signal "done" until it know there's no more work to do, which 
> > > > requires all other processes to finish up first.
> > > > 
> > > 
> > > Not all processes will need pm notification.
> > > 
> > > Just in case, could this "power manager" be provided as userspace
> > > driver for kernel (for example compiled as UIO)?
> > 
> > I don't really understand why you want to do that in the kernel.  Is there
> > any particular reason why this cannot be done in the user space?
> > 
> 
> Problem is with notification from pm-utils. Dbus for session is only 
> user session waid and it is almost imposible to send something 
> from systembus or it needs lots of magic.

Don't use dbus, then.

> Even if i'll use pm-utils, must provide way to notify my app.
> Looks like no standard way here, that's bad, every app has it's own?

Isn't there a possibility to introduce a standard way of doing that without
involving the kernel directly?

> I think this way - if kernel is processes manager and if it sends
> "some unknown" signal to every process before kernel suspend so why
> not send sepcific and known signal instread.

We _can_ do that, but what would a process be supposed to do after receiving
such a signal?

> But now we have DeviceKit-power/upower whatever but it doesn't provide
> this feature or something simmilar to relay on.

You're still not saying what you really need.  So, what's the application you
have in mind that needs a notification from the _kernel_ so badly?

Rafael

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Anders Eriksson]

uzi18@o2.pl said:
>  Ummm sorry, it's IM App, to be realible for such app it's needed to close
> conn before suspend, because after resume tcp connections will wait
> (especialy on linux) quiet a lot of time to broke and reconnect.

I don't know the details here, but shouldn't the kernel fix this internally?

If sufficient time have elapsed so the kernel _should_ have sent keep alives 
etc on an othervise idle connection, they shold be sent immediately on resume. 
If the other end has disappeared by then, the resulting port unreachable 
should trigger a local closure of the tcp state which the app will notice 
(EBADF, or similar). Or?

Seems to me the kernel should sit on enough info to handle this nicely. 

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Pavel Machek]

On Wed 2010-01-06 15:35:34, Anders Eriksson wrote:
> 
> uzi18@o2.pl said:
> >  Ummm sorry, it's IM App, to be realible for such app it's needed to close
> > conn before suspend, because after resume tcp connections will wait
> > (especialy on linux) quiet a lot of time to broke and reconnect.
> 
> I don't know the details here, but shouldn't the kernel fix this internally?
> 
> If sufficient time have elapsed so the kernel _should_ have sent keep alives 
> etc on an othervise idle connection, they shold be sent immediately on resume. 
> If the other end has disappeared by then, the resulting port unreachable 
> should trigger a local closure of the tcp state which the app will notice 
> (EBADF, or similar). Or?

Patches welcome.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Stefan Seyfried]

On Tue, 05 Jan 2010 10:07:06 +0100
Anders Eriksson <aeriksson@fastmail.fm> wrote:

> 
> rjw@sisk.pl said:
> >> > I don't see a problem with this in principle, although I don't think signals
> >> > are very suitable for this particular purpose, because you need two-way
> >> > communication between the power manager and the processes it's going to
> >> > notify (because it has to wait for the processes to finish their preparations
> >> > and to tell it that they are ready). 
> 
> Wouldn't there need to be dependecy tracking for the userspace processes? A 
> process couldn't signal "done" until it know there's no more work to do, which 
> requires all other processes to finish up first.

No. 99% of the processes don't care about suspend. They don't need
notifications or anything.
The few that do care, register themselves with the power manager. They
get notified before suspend and the power manager might wait until they
tell him that they are ready.
A special case are processes that only want to inhibit suspend - the CD
burning application case - they just tell the power manager "I am
important and you must not suspend now". They do this even if there is
no suspend notification, and once they are done with the critical part
of their work, they remove their "inhibit flag".

This all works pretty well already, and is really not very complicated.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: [linux-pm] [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 22:26 	Stefan Seyfried <stefan.seyfried@googlemail.com> napisał(a):
> > On Tue, 05 Jan 2010 10:07:06 +0100
> > Anders Eriksson <aeriksson@fastmail.fm> wrote:
> > 
> > > 
> > > rjw@sisk.pl said:
> > > >> > I don't see a problem with this in principle, although I don't think signals
> > > >> > are very suitable for this particular purpose, because you need two-way
> > > >> > communication between the power manager and the processes it's going to
> > > >> > notify (because it has to wait for the processes to finish their preparations
> > > >> > and to tell it that they are ready). 
> > > 
> > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > process couldn't signal "done" until it know there's no more work to do, which 
> > > requires all other processes to finish up first.
> > 
> > No. 99% of the processes don't care about suspend. They don't need
> > notifications or anything.
> > The few that do care, register themselves with the power manager. They
> > get notified before suspend and the power manager might wait until they
> > tell him that they are ready.
> > A special case are processes that only want to inhibit suspend - the CD
> > burning application case - they just tell the power manager "I am
> > important and you must not suspend now". They do this even if there is
> > no suspend notification, and once they are done with the critical part
> > of their work, they remove their "inhibit flag".
> > 
> > This all works pretty well already, and is really not very complicated.
> 
> So pm could be very simple, and i think we don't need more.
> I want ask You how usualy such user (not root) process notification is done,
> You are talking about pm-utils right?

Well, I think you have some specific issue with pm-utils, but you're not
telling us what it is.  So, why exactly is pm-utils not suitable for your
needs?

Rafael