linux-kernel - Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help

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] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2007 10:03:48 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	"Michael S. Tsirkin" <mst@....mellanox.co.il>
Cc:	lenb@...nel.org, Hugh Dickins <hugh@...itas.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Richard Hughes <hughsient@...il.com>
Subject: Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input
	default and kconfig help

On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > Quoting Henrique de Moraes Holschuh <hmh@....eng.br>:
> > Subject: Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
> > On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > > > I *can* make the compile-time option a module parameter, though.  That
> > > > wouldn't be much of a problem, and the compile-time option would select the
> > > > default for that parameter, but it would be easier to override it at run
> > > > time (you can already do it, but it requires reprogramming various driver
> > > > parameters using sysfs and the input device IOCTLs).
> > > > 
> > > > Would a module parameter address enough of your concerns?  Kconfig would
> > > > only set the default for that parameter, then...
> > > 
> > > I really think modifying defaults it not a great idea.
> > > What about adding a writeable module parameter?
> > > Then new HAL would just write to /sysfs/module/thinkpad/parameters/interface_version to 
> > > switch to new behaviour.
> > 
> > Nah. This thing regulates what the module has to do when it loads and inits
> > the firmware,
> 
> This does not have to be at module load time, though, does it?

Depends on how you view things.  If I do it at any other time, I will
clobber the current configuration of the module, i.e. it will be an
"autoconfig now, overriding current state" trigger.  It will also waste a
lot of memory since a big deal of stuff will stop being __init and
__initdata.

Also, it means the configuration the local admin did gets overwritten every
time HAL or something else feels the need to poke thinkpad-acpi (hopefully
once at system startup, but still...).  I consider that completely
unacceptable, because in my experience, every time you give someone such a
knob, it is abused.

And if I make it a only-one-use knob (i.e. start returning -EPERM after it
was used once), it is not much different from a module parameter, is it?
And both KISS and the principle of least suprise tells me that in that case
it better be a module parameter.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/