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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ