Re: [PATCH 7/12] acpi: fix another compile warning

[Randy Dunlap <randy.dunlap@oracle.com>]

On Fri, 22 Jun 2007 20:55:30 -0700 Andrew Morton wrote:

> > On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> > Paper over 'select' inadequacies.  
> > 
> > Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> > 
> > Index: linux-2.6.22-rc5/arch/x86_64/Kconfig
> > ===================================================================
> > --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig	2007-06-18 16:02:19.571323415 -0700
> > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig	2007-06-20 11:34:29.845354250 -0700
> > @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA
> >         depends on NUMA
> >         select ACPI 
> >  	select PCI
> > +  	select PM
> >         select ACPI_NUMA
> >         default y
> >         help
> 
> argh.  (and not just argh-at-your-email-client).
> 
> I went through some hair-tearing a few months ago working out why it is so
> damn hard to make CONFIG_PM go away and then I fixed it.  And now you're
> proposing a change which would reinstate the obnoxious old behaviour.
> 
> Is the "bug" which you're "fixing" here caused by the randconfig
> inadequacies?  Because randconfig is just busted and simply should auto-run
> oldconfig.

Running oldconfig won't fix randconfigs that have busted "select"
chains (i.e., select does not follow chains like "depends on" does).

However, lots of this bustage isn't due to randconfig at all.
It's due to Jan E.'s menuconfig changes (yes, which I supported).
It seems that Jan didn't realize that a transition of a tristate symbol
to a boolean converts y or m to y (and n to n) and all (?) of the new
menuconfig symbols that control whether a menu is displayed or not
are boolean.  One simple "fix" (or workaround) is to make them
tristate.  Now that seems a little odd for a symbol that just controls
whether a menu is displayed or not, so Satyam Sharma has made some
other suggestions, and of course Andreas Herrmann has produced lots
of patches to fix various issues that he has run into.

I can't tell you the final answer (I proposed the tristate fix).
I don't particularly like some of the patches that change
	depends on XYZ
to
	depends on XYZ && ksymbol
in many lines of kconfig entries.


Not that it answers your question, but we should have hit this
in -mm, not in mainline, but it appears that our testing was a bit
insufficient.

And of course, if someone would fix kconfig to follow "select" chains,
we should bestow an award on them.  :)
(however, I don't know if Roman would merge that patch)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***