[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.0905141154390.19537@localhost.localdomain>
Date: Thu, 14 May 2009 12:20:22 -0400 (EDT)
From: Len Brown <lenb@...nel.org>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-pci@...r.kernel.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 2/7] x86/acpi: calling mp_config_acpi_gsi in
mp_register_gsi -v2
mp_config_acpi_gsi() has been dead code since the day it went into 2.6.27.
Rather than repairing that, I'd rather see it removed.
The justification for 2944e16b25e7fb8b5ee0dd9dc7197a0f9e523cfd
"x86: update mptable" was:
1. kexec kernel with acpi=off
2. work around BIOSes where acpi routing is working, but mptable is
not right, so can use kernel/kexec to start other OSes that don't have
good acpi support.
command line: update_mptable
So this is a command line option to allow
MPS code to call into ACPI code to support kexec from an ACPI
mode into non-ACPI mode -- all without a single comment in the code.
I'm not convinced that the scenario that this code was
intended to address justifies adding unreadable code to
an area of the kernel which is notoriously over-complicated
and fragile. Doing so is the opposite of optimizing for maintenance.
No, I don't want to see any MPS code ever call into ACPI code.
thanks,
Len Brown, Intel Open Source Technology Center
--
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