From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Ferenc Wagner <wferi@niif.hu>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>,
linux-acpi@vger.kernel.org, "Rafael J.Wysocki" <rjw@sisk.pl>
Subject: Re: reverted battery current conversion fix
Date: Tue, 16 Dec 2008 12:28:32 -0200 [thread overview]
Message-ID: <20081216142832.GC13379@khazad-dum.debian.net> (raw)
In-Reply-To: <87ljuggxhf.fsf@tac.ki.iif.hu>
On Tue, 16 Dec 2008, Ferenc Wagner wrote:
> Alexey Starikovskiy <astarikovskiy@suse.de> writes:
> > Ferenc Wagner wrote:
> >> Alexey Starikovskiy <astarikovskiy@suse.de> writes:
> >>> Ferenc Wagner wrote:
> >>>> the wild values probably came from some application, which
> >>>> previously worked around the wrong sysfs current value (supposedly
> >>>> correctly interpreting it as power) and thus got broken by the fix.
> >>>
> >>> Yes, the application is kpowersaved and it is written with the
> >>> assumption that it could get remaining time by dividing either
> >>> energy_now or charge_now by current_now.
> >>
> >> So the first choice depends on the current buggy kernel behaviour.
> >> What's the plan of action in such cases? I found some notes that
> >> kpowersaved can or could use HAL for getting this information, in
> >> which case HAL also should be fixed. At least their bug tracker[1] on
> >> SF doesn't contain any such issue, maybe one should be added by
> >> somebody actually using it if the kernel is to be fixed.
> >
> > Currently, Rafael suggests, that it is too late to fix the kernel...
>
> Too late for 2.6.28 or too late for ever? The ACPI sysfs interface
> appeared about one year ago, if I read the git log right,
> documentation followed this spring. If the supposedly clean sysfs
> interface can't live up to its very precise and well thought out
> documentation, that should be documented at least. :( What a pity.
I sure hope it is "too late for 2.6.28" :-)
I can tell you what *I* do on thinkpad-acpi: I fix it, but I warn the users
beforehand, and in the release notes, and in the commit message. And I have
documented that fact in the rules of engagement for the thinkpad-acpi sysfs
interface, to make it extremely clear to all parties involved.
Note that "broken" != "not as neat as we'd like". In this case, it *is*
clearly broken, so what is happening is not a gratuitous ABI change. And if
someone in userspace worked around the broken crap, IT IS THEIR FAULT for
doing it in the first place instead of demanding that we fix the mess when
they noticed it existed.
PS: a little foresight can help wonders. I suggest adding a version
read-only attribute to the sysfs interface, and increase it when you do any
ABI change that userspace could notice (be them fixes or something else).
--
"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:[~2008-12-16 14:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87zlixxaht.fsf@szonett.ki.iif.hu>
2008-12-16 8:43 ` reverted battery current conversion fix Alexey Starikovskiy
2008-12-16 10:40 ` Ferenc Wagner
2008-12-16 10:47 ` Alexey Starikovskiy
2008-12-16 11:39 ` Ferenc Wagner
2008-12-16 14:28 ` Henrique de Moraes Holschuh [this message]
2008-12-16 15:06 ` Rafael J. Wysocki
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=20081216142832.GC13379@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=astarikovskiy@suse.de \
--cc=linux-acpi@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=wferi@niif.hu \
/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