[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1392929163.20109.5.camel@x230>
Date: Thu, 20 Feb 2014 20:46:04 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "rja@....com" <rja@....com>
CC: "lenb@...nel.org" <lenb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"minyard@....org" <minyard@....org>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH V2] Change ACPI IPMI support to "default y"
On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
> Why build a driver into the kernel?
Because it provides functionality that other drivers may need without
there being any mechanism to provide an explicit dependency. The same
reason we build the ACPI embedded controller driver into the kernel.
> The reason ipmi_si is
> a driver is so systems that want it can load it and systems
> that do not want it do not have to load it. Plus you can
> stop/start modules without rebooting. You can change module
> parameters without rebooting.
You can change module parameters without rebooting anyway - there's an
interface for it in sysfs.
> There are any number of reasons why a BMC may not respond.
> BMCs are notorious for being flakey, with different types
> of BMCs that may or may not be reliable. You do not want
> to make the kernel boot dependent on an unreliable component.
You appear to be saying "SGI ship hardware that doesn't work. We don't
know why it doesn't work and we're not interested in fixing it, so we'd
prefer the default kernel configuration to be broken". That doesn't seem
like an especially compelling argument.
> This is also a problem for systems with functional BMCs. Our
> large cluster systems do all IPMI traffic (monitoring) through
> a system controller back door. We do not want the kernel
> doing IPMI commands on those systems.
Why not?
--
Matthew Garrett <matthew.garrett@...ula.com>
Powered by blists - more mailing lists