linux-kernel - Re: [PATCH] x86: let MPS support selectable

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: <Pine.LNX.4.55.0806191920080.12929@cliff.in.clinika.pl>
Date:	Thu, 19 Jun 2008 19:48:51 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Len Brown <lenb@...nel.org>
cc:	Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Exner <dex@...gonslave.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: let MPS support selectable

On Thu, 19 Jun 2008, Len Brown wrote:

> CONFIG_ACPI_BOOT was removed because it was fundamentally ill-conceived
> and created a situation which was not only more difficult to maintain
> but also didn't work on most machines.
> ACPI interrupt configuration depends on the ACPI interpreter, so to boot
> properly and configure interrupts with ACPI, you need 90% of the kernel's
> ACPI code present anyway.

 Fair enough.

> If you want to use ACPI just for enumerating processors, ie to see
> the HT that MPS usually doesn't include, you can boot with "acpi=ht",
> which will not enter ACPI mode or use ACPI for anything else.

 Hmm, that's quite obscure an option name!  I would imagine most modern
systems used as servers would not want to do any power management, but
would still prefer to use ACPI for enumeration of processors (including
real ones!) and interrupts, because I gather it has become common if an MP
table is included in a system at all, it is not exactly correct, because
the responsible BIOS engineer simply had no clue to either fix it or
discard entirely.

> I don't think we should be going out of our way to enhance MPS support.
> There probably isn't a single system shipped in this century that has MPS
> that doesen't have ACPI, while there are millions of systems that
> have ACPI and no MPS.  MPS is going away, and making

 It looks like I have a fortunate exception, manufactured Dec 2007, which
has both in quite a good shape. :)

> it a config option prepares us for the day when we completely
> don't care about it any more.

 Well, this is why I think it is important to be able to drop unwanted
parts of the framework, such as the P from the ACPI acronym.  If you say
"acpi=ht" will do, that's great; otherwise relying on the MP table used to
be the alternative.

 I don't think we'll be able to drop MP table support entirely in the
foreseeable future though, like we haven't dropped support for the
original 80386 yet.  Old SMP systems with MP table support only are going
to be around for a while -- I have a couple myself and I am sure they are
still quite common.

> However, I think that adding CONFIG_MPS before removing ACPI's
> depencency on mpparse.c has all risk and no value.

 Agreed.

  Maciej
--
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/