[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B406C14.2070907@gmail.com>
Date: Sun, 03 Jan 2010 11:06:12 +0100
From: Daniel Borkmann <danborkmann@...glemail.com>
To: Bartłomiej Zimoń <uzi18@...pl>
CC: "Rafael J. Wysocki" <rjw@...k.pl>, Andy Walls <awalls@...ix.net>,
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
Daniel Borkmann wrote:
> Bartłomiej Zimoń wrote:
>> What about this discusion:
>> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html
>>
>> I will perform some tests to know what amount of time is usualy needed to disconnect
>> nicely client or something.
>
> Actually I think this is what signals are there for and bringing this
> information via signals would have least overhead, problem is that this
> is not POSIX compliant, but may be you could have a try at this?!
I'm not quite sure how this is implemented within the kernel, but if you
have lots of processes doing their suspend routines, I think it is not
guaranteed that all of this finishes before doing the suspend, so you
will have some unknown states, processes could stuck at (and later [at
some unintended point of time] resume on).
Or, on the other hand you will have to block the kernel notification
chain until all the procs have signaled that they're done doing their
jobs. Regarding this, the kernel suspend would depend on the correctness
/ termination of userspace routines which is a _very_ bad thing.
You will have to introducte some timeouts... see where this is going? I
think a file interface might be too simple... just some thoughts about this.
Regards,
Daniel
Download attachment "signature.asc" of type "application/pgp-signature" (262 bytes)
Powered by blists - more mailing lists