From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: "Michael S. Tsirkin" <mst@dev.mellanox.co.il>
Cc: lenb@kernel.org, Hugh Dickins <hugh@veritas.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Richard Hughes <hughsient@gmail.com>
Subject: Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
Date: Thu, 16 Aug 2007 09:25:06 -0300 [thread overview]
Message-ID: <20070816122506.GA5081@khazad-dum.debian.net> (raw)
In-Reply-To: <20070816073053.GA19833@mellanox.co.il>
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, 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.
--
"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
next prev parent reply other threads:[~2007-08-16 12:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11868017142597-git-send-email-hmh@hmh.eng.br>
[not found] ` <11868017143582-git-send-email-hmh@hmh.eng.br>
2007-08-11 18:06 ` Michael S. Tsirkin
2007-08-11 22:16 ` Henrique de Moraes Holschuh
2007-08-16 7:30 ` Michael S. Tsirkin
2007-08-16 12:25 ` Henrique de Moraes Holschuh [this message]
2007-08-16 12:28 ` Michael S. Tsirkin
2007-08-16 13:03 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070816122506.GA5081@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=hugh@veritas.com \
--cc=hughsient@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@dev.mellanox.co.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®