linux-kernel - Re: ACPI build problem (2.6.21 CONFIG_X86_64_ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070430182838.GA5558@localhost.localdomain>
Date:	Mon, 30 Apr 2007 11:28:38 -0700
From:	Ravikiran G Thirumalai <kiran@...lex86.org>
To:	Len Brown <lenb@...nel.org>
Cc:	Steven Whitehouse <swhiteho@...hat.com>, Andi Kleen <ak@...e.de>,
	Shai Fultheim <shai@...lex86.org>, linux-kernel@...r.kernel.org
Subject: Re: ACPI build problem (2.6.21 CONFIG_X86_64_ACPI_NUMA)

On Sat, Apr 28, 2007 at 01:59:46AM -0400, Len Brown wrote:
> On Thursday 26 April 2007 09:26, you wrote:
> ... 
> CONFIG_ACPI depends on CONFIG_PM, yet this build fails because you have
> CONFIG_ACPI=y and CONFIG_PM=n
> 
> Unfortunately kconfig doesn't trace dependencies when "select" is used,
> making select sort of evil.  Ie. select can't target anything which
> itself has dependencies.
> 
> In 2.6.15, b0bd35e622ffbda2c01dc67a0381c6a18817a29a added the select below,
> and subsequently ACPI became dependent on PM, which broke your build.
> Technically, this could have broken your build in other ways too
> since ACPI already had other dependencies.
> 
> +# Dummy CONFIG option to select ACPI_NUMA from drivers/acpi/Kconfig.
> +
> +config X86_64_ACPI_NUMA
> +       bool "ACPI NUMA detection"
> +       depends on NUMA
> +       select ACPI 
> +       select ACPI_NUMA
> +       default y
> +       help
> +	 Enable ACPI SRAT based node topology detection.
> 
> If you de-select CONFIG_X86_64_ACPI_NUMA then the select goes away
> and kconfig should work properly.
> 
> It isn't immediately clear to me how the NUMA Kconfig patch is a step
> forward, but perhaps the authors can comment.
>

Before the above change, to select NUMA for em64T systems, you *had* to
select K8_NUMA in the 'Processor type and features'  sub menu to select
CONFIG_NUMA, and then select ACPI NUMA from the generic PM menu, which is
not very intuitive when you have a EM64T NUMA system.

On x86_64 platforms, NUMA topology detection could be K8 style detection,
ACPI based topology  or NUMA emulation.  Most of the real NUMA systems
would need ACPI detection, older AMD platforms would need K8_NUMA, and 
NUMA emulation is a debugging/emulation option to emulate NUMA topology on
a regular SMP box.  Since CONFIG_NUMA + CONFIG_NUMA_EMU is a valid
combination, and since CONFIG_NUMA + CONFIG_K8_NUMA is a valid combination,
it makes sense to have X86_64_ACPI_NUMA on its own, and grouped along with
other NUMA topology styles in the Processor menu.  Hope this is good enough
reason :)

Regarding the subject build breakage, CONFIG_ACPI depends on CONFIG_PM with
an explicit 'depends' keyword. If PM does not get selected and CONFIG_ACPI
gets selected, I would think it is a Kconfig bug which needs fixing no?
Else, we can add a workaround by selecting CONFIG_PM if X86_64_ACPI_NUMA is
chosen.  But AFAICT the right thing is to fix the Kconfig bug.

Thanks,
Kiran
-
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/