| |||||||||||||
Removing four bytes from the kernel ABIRemoving four bytes from the kernel ABIPosted May 25, 2012 19:34 UTC (Fri) by nevets (subscriber, #11875)In reply to: Removing four bytes from the kernel ABI by drag Parent article: Removing four bytes from the kernel ABI
>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.
BruhahahaHAHAH! The kernel 0wns your box! Why do you think we became kernel developers?
WORLD DOMINATION!
(Log in to post comments)
Removing four bytes from the kernel ABI Posted May 28, 2012 13:10 UTC (Mon) by nix (subscriber, #2304) [Link]
Quite. Why hack the binaries when you can have binfmt_elf.c detect affected binaries at runtime and slam in a binary patch? Plus, that works everywhere (FSVO 'everywhere' equal to 'on the machine it was tested on') and makes debugging when you don't know the feature is there so much more exciting!
(I wish I was joking, but Windows does exactly this routinely.)
Removing four bytes from the kernel ABI Posted May 29, 2012 19:21 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
So far as I know Windows doesn't patch third-party code in memory, but it does enable compatibility quirks on a per-process basis based on recognition of certain programs. In some cases that approach may be superior to maintaining the old behaviour for all programs - the usual reason for wanting to change the implementation is to improve performance, and Windows can provide that improvement for most programs.
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.
|
|||||||||||||