Re: [PATCH] PM: Hide CONFIG_PM from users

Hi Mark,

On Mon,  7 Feb 2011 12:22:15 +0000 Mark Brown [off-list ref] wrote:

Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
server configs), so this will unexpectedly turn it on for them.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:

On Mon,  7 Feb 2011 12:22:15 +0000 Mark Brown [off-list ref] wrote:

quoted

+	bool
+	default y if !IA64_HP_SIM

Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
server configs), so this will unexpectedly turn it on for them.

Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on?  If the latter would you expect any
ill effects from doing so?

Hi Mark,

On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown [off-list ref] wrote:

On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:

quoted

On Mon,  7 Feb 2011 12:22:15 +0000 Mark Brown [off-list ref] wrote:

quoted

quoted

+	bool
+	default y if !IA64_HP_SIM

quoted

Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
server configs), so this will unexpectedly turn it on for them.

Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on?  If the latter would you expect any
ill effects from doing so?

I don't know the answer to either question without testing.  All I am
saying is that currently the default for CONFIG_PM is "off" and you are
changing it to be "on" and there may not have been any testing done of
that in some situations.   We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:

On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown [off-list ref] wrote:

quoted

Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on?  If the latter would you expect any
ill effects from doing so?

I don't know the answer to either question without testing.  All I am
saying is that currently the default for CONFIG_PM is "off" and you are
changing it to be "on" and there may not have been any testing done of
that in some situations.   We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.

My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.

On Mon, Feb 7, 2011 at 15:50, Mark Brown
[off-list ref] wrote:

On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:

quoted

On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfson=

micro.com> wrote:

quoted

quoted

Do you mean that these systems require CONFIG_PM be turned off, or jus=

t

quoted

quoted

that people tend not to turn it on? =C2=A0If the latter would you expe=

ct any

quoted

quoted

ill effects from doing so?

quoted

I don't know the answer to either question without testing. =C2=A0All I =

am

quoted

saying is that currently the default for CONFIG_PM is "off" and you are
changing it to be "on" and there may not have been any testing done of
that in some situations. =C2=A0 We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.

My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.

$ git grep "CONFIG_PM is not set"
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$

7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

Hi Geert,

On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven [off-list ref] wrote:

$ git grep "CONFIG_PM is not set"
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$

7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.

Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
defconfigs, or just off because noone explicitly turned it on.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Tue, 8 Feb 2011 02:10:45 +1100 Stephen Rothwell [off-list ref] wrote:

On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven [off-list ref] wrote:

quoted

$ git grep "CONFIG_PM is not set"
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$

7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.

Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
defconfigs, or just off because noone explicitly turned it on.

At least some of the powerpc defconfigs were added with CONFIG_PM
disabled.  I assume that was on purpose (though it may not have been).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:

At least some of the powerpc defconfigs were added with CONFIG_PM
disabled.  I assume that was on purpose (though it may not have been).

I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.

On Mon, 7 Feb 2011, Mark Brown wrote:

On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:

quoted

At least some of the powerpc defconfigs were added with CONFIG_PM
disabled.  I assume that was on purpose (though it may not have been).

I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.

This may be a naive suggestion, but have you considered simply _asking_
the people who added those defconfigs?

Alan Stern

On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:

On Mon, 7 Feb 2011, Mark Brown wrote:

quoted

I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.

This may be a naive suggestion, but have you considered simply _asking_
the people who added those defconfigs?

I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does - as Geert pointed
out there's a considerable number of defconfigs that have this turned
off.  It seems more sensible to get some idea if this seems sane to
people in the general case before going trying to identify and contact
so many individuals.

If there are systems that really require disabling CONFIG_PM we probably
need to add stuff to Kconfig to make sure it can't be enabled anyway;
this shouldn't enable any new configurations.

On Monday, February 07, 2011, Mark Brown wrote:

On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:

quoted

On Mon, 7 Feb 2011, Mark Brown wrote:

quoted

quoted

I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.

quoted

This may be a naive suggestion, but have you considered simply _asking_
the people who added those defconfigs?

I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does - as Geert pointed
out there's a considerable number of defconfigs that have this turned
off.  It seems more sensible to get some idea if this seems sane to
people in the general case before going trying to identify and contact
so many individuals.

If there are systems that really require disabling CONFIG_PM we probably
need to add stuff to Kconfig to make sure it can't be enabled anyway;
this shouldn't enable any new configurations.

Well, as I've just said, I don't like this change.  I'd very much prefer it if
CONFIG_PM_OPS were renamed to CONFIG_PM.

Thanks,
Rafael

On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown
[off-list ref] wrote:

I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does

Surely you're joking. I mean, do _you_ scan every message that comes
through lkml and its various sister lists?

Do a git blame and add them to the CC:. It's the polite thing to do.

On Mon, Feb 07, 2011 at 05:17:59PM -0800, Ray Lee wrote:

On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown

quoted

I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does

Surely you're joking. I mean, do _you_ scan every message that comes
through lkml and its various sister lists?

Actually I do at least scan most of the lists.

Do a git blame and add them to the CC:. It's the polite thing to do.

It's also going to result in the mail not going to the mailing lists as
there's a limit on the number of people you can CC enforced by vger
which probably isn't constructive.  It's moot now but as I said in the
text you've helpfully cut I'd have suggested contacting them after the
thread had come to a conclusion.