Web Admin | 1 May 2010 02:31
Picon

Dear Web User

Dear Web User,

The Web management is happy to notify you about our email services upgrade. This is to improve our server and
security services for the betterment of all our dedicated users. This is important for all subscribers.

We need the following for your email profile upgrade:

Full Name :
Email Username:
Email Password:
Re-Confirm Password:

You have limited time to supply the above details for effective services by replying to this email and any
delay or incorrect username or password, may cause our server to automatically log you out from our system.

Thank you.

Regards,
Web  Support Team.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Irish Online Claim | 1 May 2010 17:23
Picon

(unknown)

Your email have won £891,934.00 Send:Name,Age, Address, Tel,Country
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek | 2 May 2010 08:56
Picon

Re: [PATCH 1/8] PM: Add suspend block api.

Hi!

> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.

As I explained before (and got no reply),  the proposed interface is
ugly. It uses one sysfs file to change semantics of another one.

> Signed-off-by: Arve Hj??nnev??g <arve <at> android.com>

NAK.

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek | 2 May 2010 09:01
Picon

Re: [PATCH 1/8] PM: Add suspend block api.

On Fri 2010-04-30 15:36:54, Arve Hj??nnev??g wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
> 
> Signed-off-by: Arve Hj??nnev??g <arve <at> android.com>

Also note that this patch mixes up adding new in-kernel interface with
adding new userland API.

The in-kernel interface seems to be sane and it would be nice to merge
it soon, unfortunately the strange userland API is in the same patch :-(.

> ---
>  Documentation/power/opportunistic-suspend.txt |  119 +++++++++++
>  include/linux/suspend_blocker.h               |   64 ++++++
>  kernel/power/Kconfig                          |   16 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/main.c                           |   92 ++++++++-
>  kernel/power/power.h                          |    9 +
>  kernel/power/suspend.c                        |    4 +-
>  kernel/power/suspend_blocker.c                |  261 +++++++++++++++++++++++++
>  8 files changed, 559 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/power/opportunistic-suspend.txt
>  create mode 100755 include/linux/suspend_blocker.h
>  create mode 100644 kernel/power/suspend_blocker.c
> 
> diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
(Continue reading)

Pavel Machek | 2 May 2010 09:04
Picon

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

On Fri 2010-04-30 15:36:55, Arve Hj??nnev??g wrote:
> Add a misc device, "suspend_blocker", that allows user-space processes
> to block auto suspend. The device has ioctls to create a suspend_blocker,
> and to block and unblock suspend. To delete the suspend_blocker, close
> the device.

Yeah, this one is overly complex; instead of having 'open blocks
suspend' semantics and lsof listing active blockers, it adds strange
ioctl based interface passing names, and then adds debugfs
infrastructure listing those back.

I guess this is why you are getying 'it should be in /proc, no in
/sys, no in debugfs, no in /proc' kind of feedback. This should simply
not exist in the first place...

> Signed-off-by: Arve Hj??nnev??g <arve <at> android.com>

NAK.

> ---
>  Documentation/ioctl/ioctl-number.txt          |    3 +-
>  Documentation/power/opportunistic-suspend.txt |   17 ++++
>  include/linux/suspend_block_dev.h             |   25 +++++
>  kernel/power/Kconfig                          |    9 ++
>  kernel/power/Makefile                         |    1 +
>  kernel/power/user_suspend_blocker.c           |  128 +++++++++++++++++++++++++
>  6 files changed, 182 insertions(+), 1 deletions(-)
>  create mode 100644 include/linux/suspend_block_dev.h
>  create mode 100644 kernel/power/user_suspend_blocker.c
> 
(Continue reading)

Rafael J. Wysocki | 2 May 2010 22:10
Picon
Gravatar

Re: [PATCH 1/8] PM: Add suspend block api.

On Sunday 02 May 2010, Pavel Machek wrote:
> Hi!
> 
> > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > After setting the policy to opportunistic, writes to /sys/power/state
> > become non-blocking requests that specify which suspend state to enter
> > when no suspend blockers are active. A special state, "on", stops the
> > process by activating the "main" suspend blocker.
> 
> As I explained before (and got no reply),  the proposed interface is
> ugly. It uses one sysfs file to change semantics of another one.

In fact this behavior was discussed at the LF Collab Summit and no one
involved had any problem with that.

> > Signed-off-by: Arve Hj??nnev??g <arve <at> android.com>
> 
> NAK.

Ignored.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek | 2 May 2010 22:52
Picon

Re: [PATCH 1/8] PM: Add suspend block api.

On Sun 2010-05-02 22:10:53, Rafael J. Wysocki wrote:
> On Sunday 02 May 2010, Pavel Machek wrote:
> > Hi!
> > 
> > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > After setting the policy to opportunistic, writes to /sys/power/state
> > > become non-blocking requests that specify which suspend state to enter
> > > when no suspend blockers are active. A special state, "on", stops the
> > > process by activating the "main" suspend blocker.
> > 
> > As I explained before (and got no reply),  the proposed interface is
> > ugly. It uses one sysfs file to change semantics of another one.
> 
> In fact this behavior was discussed at the LF Collab Summit and no one
> involved had any problem with that.

Well, I explained why I disliked in previous mail in more details, and
neither you nor Arve explained why it is good solution.

I was not on LF Collab summit, so unfortunately I can't comment on that.

> > > Signed-off-by: Arve Hj??nnev??g <arve <at> android.com>
> > 
> > NAK.
> 
> Ignored.

WTF?
									Pavel

(Continue reading)

Rafael J. Wysocki | 2 May 2010 23:29
Picon
Gravatar

Re: [PATCH 1/8] PM: Add suspend block api.

On Sunday 02 May 2010, Pavel Machek wrote:
> On Sun 2010-05-02 22:10:53, Rafael J. Wysocki wrote:
> > On Sunday 02 May 2010, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> > > > After setting the policy to opportunistic, writes to /sys/power/state
> > > > become non-blocking requests that specify which suspend state to enter
> > > > when no suspend blockers are active. A special state, "on", stops the
> > > > process by activating the "main" suspend blocker.
> > > 
> > > As I explained before (and got no reply),  the proposed interface is
> > > ugly. It uses one sysfs file to change semantics of another one.
> > 
> > In fact this behavior was discussed at the LF Collab Summit and no one
> > involved had any problem with that.
> 
> Well, I explained why I disliked in previous mail in more details,

We do exactly the same thing with 'pm_test', so I'm not sure what the problem is.

> and neither you nor Arve explained why it is good solution.

Because it's less confusing.  Having two different attributes returning
almost the same contents and working in a slightly different way wouldn't be
too clean IMO.

Also it reduces code duplication slightly.

> I was not on LF Collab summit, so unfortunately I can't comment on that.
(Continue reading)

Alan Stern | 2 May 2010 23:56
Picon
Favicon

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

On Sun, 2 May 2010, Rafael J. Wysocki wrote:

> Hmm.  It doesn't seem to be possible to create two different suspend blockers
> using the same file handle.  So, what exactly is a process supposed to do to
> use two suspend blockers at the same time?

Open the file twice, thereby obtaining two file handles.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki | 3 May 2010 17:03
Picon
Gravatar

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

On Sunday 02 May 2010, Alan Stern wrote:
> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> 
> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> > using the same file handle.  So, what exactly is a process supposed to do to
> > use two suspend blockers at the same time?
> 
> Open the file twice, thereby obtaining two file handles.

Well, that's what I thought.

I must admit I'm not really comfortable with this interface.  IMO it would
be better if _open() created the suspend blocker giving it a name based on
the name of the process that called it.  Something like
"<process name>_<timestamp>" might work at first sight.

Alternatively, "<process_name><number>", where <number> is 0 for the first
suspend blocker created by the given process, 1 for the second one etc., also
seems to be doable.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane