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

Message-ID: <20070816122823.GH5684@mellanox.co.il>
Date:	Thu, 16 Aug 2007 15:28:23 +0300
From:	"Michael S. Tsirkin" <mst@....mellanox.co.il>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	"Michael S. Tsirkin" <mst@....mellanox.co.il>, 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

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

> and the whole point of the new behaviour is to get userspace
> to be as hands' off as possible, so that we can auto-tune things better
> in-kernel, without a need to worry about HAL and friends overwriting local
> admin configurations needlessly.
> 
> I will probably have to do something like the strict versioned interfaces of
> wireless extensions, I think. It really is a case of a deprecation of
> current userland interfaces done sanely.  Right now I am thinking about
> giving userland two kernel releases before I change the default interface
> level, and one to two years to remove the older ones.

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