From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: astarikovskiy@suse.de, linux-acpi@vger.kernel.org
Subject: Re: [RFC] EC registers - Adding sysfs interface?
Date: Wed, 14 Nov 2007 00:40:49 -0200 [thread overview]
Message-ID: <20071114024049.GA10677@khazad-dum.debian.net> (raw)
In-Reply-To: <200711131724.31868.carlos@strangeworlds.co.uk>
On Tue, 13 Nov 2007, Carlos Corbacho wrote:
> I'm considering writing a sysfs interface for the EC registers, and was
> wondering if you would be ok with such a patch (before I start work on it)?
I have exactly such a beast in thinkpad-acpi (using /proc, though),
inherited from ibm-acpi who has had it for a LONG while. So, I feel
entitled to share some of my experiences with it...
To make it short:
1. It is dangerous. There is no other way to look at it. Even reads can
have side-effects on some boxes. Writing can do *very* dangerous
things. So, it is a "use it only when told to by someone who actually
knows what it does" tool for the vast majority out there.
2. Users will enable it even if they don't know what they're doing, and they
will use it as if it were just yet another toy, no matter how many
warnings you give them. They will place scripts using it on Wikis, and
you will get to hear about it for a long, long time.
3. Unless you stick *heavy* warnings, and require explicit enabling through
module parameters/kernel command line, distros will enable it and *you*
will get the blame and complains when it blows up something.
4. A binary attribute that can handle mmap() is a much better interface
IMHO (or just use a plain UNIX char device).
So, while I am *for* adding such a thing (it has proved to be useful on
thinkpads), I'd say you should at least require a lot of steps to enable it,
and I do NOT mean a sysfs "write 1 here to enable" attribute.
I am against the idea of providing this as a regular (non-debug) tool for
usespace to poke at, for the simple reason that once you have "userspace
drivers" messing with it, all hope is lost to track the hardware state on
write-only registers.
--
"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
prev parent reply other threads:[~2007-11-14 3:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 17:24 [RFC] EC registers - Adding sysfs interface? Carlos Corbacho
2007-11-13 18:40 ` Alexey Starikovskiy
2007-11-13 18:46 ` Alexey Starikovskiy
2007-11-13 18:49 ` Carlos Corbacho
2007-11-13 18:54 ` Alexey Starikovskiy
2007-11-13 19:03 ` Carlos Corbacho
2007-11-28 16:28 ` Thomas Renninger
2007-11-28 18:25 ` Alexey Starikovskiy
2007-11-28 23:12 ` Henrique de Moraes Holschuh
2007-12-07 2:52 ` Len Brown
2007-12-07 8:53 ` Thomas Renninger
2007-12-10 20:36 ` Henrique de Moraes Holschuh
2007-11-14 2:40 ` Henrique de Moraes Holschuh [this message]
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=20071114024049.GA10677@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=astarikovskiy@suse.de \
--cc=carlos@strangeworlds.co.uk \
--cc=linux-acpi@vger.kernel.org \
/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