Date:	Thu, 26 Jul 2007 13:45:29 -0400
From:	Len Brown <lenb@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	david@...g.hm, Andrew Morton <akpm@...ux-foundation.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

On Thursday 26 July 2007 02:55, Linus Torvalds wrote:
> 
> On Thu, 26 Jul 2007, Len Brown wrote:
> > 
> > Feel free to share what you know about the benefits vs. the costs
> > of maintaining CONFIG_ACPI_SLEEP as a build option.
> 
> Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND 
> and STR?

CONFIG_STR doesn't exist.

I agree it is an attractive notion to have a high level feature presented
to the user, and that the tools should select what is needed to satisfy the
user's request.  Unfortunately Kconfig is exceptionally bad at supporting
this model.  "depend" frustrates users by making config options vanish
without explanation, and "select" is fundamentally broken
because it doesn't enforce dependencies.

> > If you feel that your system has been degraded
> > because it now includes what used to be excluded under
> > CONFIG_ACPI_SLEEP=n, please let me know how.
> 
> I feel that I get asked to include a feature that
>  (a) I have no interest in on that machine
>  (b) I didn't need to include before.
> 
> What was the advantage? And what was it that caused something like this to 
> be a post-rc1 thing. That makes me really unhappy. This is a *regression*.

I'm sorry that one fewer config options has offended your feeling of freedom,
honestly, I am.

I was actually asking how somebody's _system_ has been degraded
by this change -- but I haven't got an objective answer to that one yet.

As I said in my pull request, I agree that the D-state fixes ideally
should have merged a week earlier -- before the rc1 cutoff.
Indeed, we had a hack that could have gone up much earlier.
However, we waited for Rafael's more general list-blessed solution --
and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n.

The reason is because there is a dependency between D-states and S-states.
In particular, devices which are enabled to be system wakeup devices
can be limited in what D-states they can enter (else they may
no longer be able to wake up the system when it is suspended)

I figured that rather than adding more ifdefs to solve that problem,
it was simpler to remove ifdefs.  I was also shocked to find i386 defconfig
with CONFIG_ACPI_SLEEP=n.  Maybe others are not shocked by this
and there is a reason that defconfig on x86_64 supports sleep
and i386 does not.  I assumed it was a bug, maybe I was wrong.

The context for this is the EPA ENERGY STAR specification for Computers,
which went into effect this month.  This spec says that systems which
can not automatically go into suspend within 15 minutes of idle
can _not_ earn a sticker.  No sticker, no client computer sales to governments.
If Linux can't get STR working, broadly deployed, and enabled by default,
then our plans for world domination are going to take a significant hit.

yes, I understand that there are SMP systems that want ACPI and don't
need sleep or CONFIG_HOGPLUG_CPU.  However, I don't see major distros
shipping kernels to their server customers that way, so I didn't think
it would offend a significant part of the community's sense of freedom
if this config option were removed.  Maybe I was wrong.

Obviously, your vote counts more than the sum total of a lot of the community,
so if you want me to put a config option in to allow ACPI w/o ACPI_SLEEP,
I'll simply do it for you.  However, I could do a better job of it
if I had a clear understanding of what the technical benefit of
that option is supposed to be, and how it will make Linux better.

-Len
-
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