On Tuesday, 16 of December 2008, Henrique de Moraes Holschuh wrote: > On Tue, 16 Dec 2008, Ferenc Wagner wrote: > > Alexey Starikovskiy <astarikovskiy@xxxxxxx> writes: > > > Ferenc Wagner wrote: > > >> Alexey Starikovskiy <astarikovskiy@xxxxxxx> 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... Actually no, I didn't say that. What I said is that it was too late to change the interpretation of 'current_now' in the case when energy units were used. > > 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" :-) For 2.6.28 it's obviously too late, but I think it generally is too late to change whatever is reported via 'current_now', because the userland already started to rely on that. > 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. That only is a semantic difference. The breakage is actually the same. > 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. I think they didn't understand the interface and found the working settings by experimentation. It's not their fault that had to do that. > 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). Good idea, but it doesn't help in this particular case. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
