Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Removing four bytes from the kernel ABI
Posted May 24, 2012 10:47 UTC (Thu) by intgr (subscriber, #39733)
The problem is PowerTOP 1.9x versions, which are actually prereleases (beta) of 2.0, but already shipped by some distros. In my opinion, they should just update to 2.0 since it's a bugfix update over the 1.9x branch.
> It was, however, easier to read the data directly rather than parse the format description, which is why PowerTOP did so
Well, sounds to me like the kernel didn't actually break its promised ABI -- PowerTOP didn't respect the event description so it misused the ABI.
Posted May 24, 2012 15:57 UTC (Thu) by nevets (subscriber, #11875)
True but unfortunately that doesn't matter. As Linus pointed out:
And if binaries don't use the interface to parse the format (or just parse it wrongly - see the fairly recent example of adding uuid's to /proc/self/mountinfo), then it's a regression.
If you made an interface that can be used without parsing the interface description, then we're stuck with the interface. Theory simply doesn't matter.
Basically it came down to the fact that we didn't push the library that parses the data strong enough. And we also made it too easy for apps to circumvent the library. Peter Zijlstra once asked me to make the field order random, to keep tools from doing this (before PowerTop actually did), but to do so would have added a high overhead to tracing, that I did not think was worth it at the time. Then when this happened, I realized that I was mistaken.
If the author of PowerTop wasn't a kernel developer, I highly doubt we would have had this problem. But the author was and for him, it was much easier to look at what the kernel code was doing and access it directly than to create a parsing library. I do not blame him for this. It was our fault for letting this happen.
Posted May 25, 2012 0:20 UTC (Fri) by giraffedata (subscriber, #1954)
If you made an interface that can be used without parsing the interface description, then we're stuck with the interface.
Linus is always oversimplifying things. I know he doesn't really believe that the kernel is stuck with an interface just because kernel developers made it possible for someone to consider it to exist. It simply isn't technically possible to prevent someone from using an intended interface that wasn't intended.
Linus' real and more reasonable policy would probably be better exemplified by:
If an important user found a way to use your interface without parsing the interface description, then we're stuck with the interface.
Posted May 25, 2012 6:32 UTC (Fri) by drag (subscriber, #31333)
How can they do that?
Last time I checked Linux kernel developers don't have a back door that will allow them to update random affect binaries on my machines when I update the kernel. At least I hope not.
Posted May 25, 2012 19:34 UTC (Fri) by nevets (subscriber, #11875)
BruhahahaHAHAH! The kernel 0wns your box! Why do you think we became kernel developers?
Posted May 28, 2012 13:10 UTC (Mon) by nix (subscriber, #2304)
(I wish I was joking, but Windows does exactly this routinely.)
Posted May 29, 2012 19:21 UTC (Tue) by BenHutchings (subscriber, #37955)
Linux does have per-process compatibility quirks (see setarch(8)) but no provision for enabling them automatically. I'm not sure why, though it may be that such recognition would be better implemented in userland.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds