Follow Slashdot stories on Twitter


Forgot your password?
Open Source Operating Systems Upgrades Linux

Linux Getting Extensive x86 Assembly Code Refresh 209

jones_supa writes: A massive x86 assembly code spring cleaning has been done in a pull request that is to end up in Linux 4.1. The developers have tried testing the code on many different x86 boxes, but there's risk of regression when exposing the code to many more systems in the days and weeks ahead. That being said, the list of improvements is excellent. There are over 100 separate cleanups, restructuring changes, speedups and fixes in the x86 system call, IRQ, trap and other entry code, part of a heroic effort to deobfuscate a decade old spaghetti assembly code and its C code dependencies.
This discussion has been archived. No new comments can be posted.

Linux Getting Extensive x86 Assembly Code Refresh

Comments Filter:
  • Debt (Score:5, Insightful)

    by Ducho_CWB ( 900642 ) on Monday April 13, 2015 @07:36PM (#49466597)

    Technical Debt haunts you.

    • Re:Debt (Score:5, Insightful)

      by Darinbob ( 1142669 ) on Monday April 13, 2015 @08:54PM (#49467037)

      Yes, if it weren't for the idea that I could change jobs if I needed to, I'd have been full of hopless dread at just about most places I've worked. The sad thing is, in some places the majority of technical debt is creating in the first year of the company's existence, during the hurry-up-already startup phase.

      • Thats not really the debt though. The debt is when you get a giant wad of funding and dont take the time to greenfield your cludge app.
        • Thats not really the debt though. The debt is when you get a giant wad of funding and dont take the time to greenfield your cludge app.

          No, that is debt, and in many cases it is the biggest single source of debt, as Darinbob said. Failing to rewrite your kludge app is just failing to pay down your debt. Whether or not the moment you get a giant wad of funding is the right time to do that depends on the context.

  • by Anonymous Coward

    We live in interesting times these days. With a changeset so big, and involving assembly code that isn't as easy to understand as C code, how can we really be sure that no exploits have been introduced? How extensively have these changes been reviewed to ensure there are no exploits or potential exploits being sneaked in?

    • by Lunix Nutcase ( 1092239 ) on Monday April 13, 2015 @07:44PM (#49466655)

      The only way to truly understand C code is to read the disassembly. Otherwise you are only assuming what the compiler is emitting.

      • Re: (Score:2, Funny)

        That does not fit in with the concepts of 'abstraction' that are fashionable. No 'coder' should really need to understand the actual code the hardware runs. It's all rife with gotos and other icky things. Pointers (physical memory addresses) and stuff get revealed.

        No! Mommy! Make the bad hardware go away!

        • by Rigel47 ( 2991727 ) on Monday April 13, 2015 @11:51PM (#49467733)
          I do enjoy how we tech people less-than-quietly display our scorn of all the varying fields in IT that aren't our own. Because, hah, stupid Javascript developer, couldn't explain northbridge from south! Or what DMA is! He probably doesn't know a single assembly instruction! Clearly an inferior being.

          Javascript guy meanwhile regards the C guy as a primitive, bearded man from the hills who labors all day on some stupid library that is ten layers of stack between that mortar and pestle and the awesome browser-art he's creating.

          Systems administrators wish everyone would run off and die because they are all irritating, stupid whiners.

          DBAs are just smug because nobody else understands their schemas and, hey, this is where it all happens.

          Networking would rather be back below the hold, No, the network isn't broken, your app is buggy or the stupid website you're trying to load is just slow..

          Help desk guys meanwhile consider themselves the cocks of the walk because, generally, their camaraderie and opportunity to interact with more regular people means their souls haven't been totally crushed.
          • Re: (Score:3, Funny)

            by Anonymous Coward

            Jokes on you. I'm building a VM language in ASM.js and VM bytecode. I get to deal with memory management and multiprocessing issues that are unique to ASM.js. Since the code compiles to opcode which can then be output as "native" ASM.js (which is then mostly compiled to machine code by browsers) or it can run blazing fast on the C VM implementation with its (native) JiT optimizations. Since the platform is meant to be an extremely portable high level and systems level language I'm currently implementing

          • Chorus:

            "Well, It's Simple! All You Have To Do Is..."

          • by houghi ( 78078 )

            And all this fingerpointing leads to confused users (who are the worst as they are demanding it to just work).
            I had an issue with displaying things on Windowmaker, while it worked on XFCE.
            Windowmaker pointed to They pointed to NVidia who pointed to Windowmaker.

            "It wasn't me." was all the feedback I got. No way they would talk to each other, because their code was perfect.

            As if two ISP's only check their network so the connection problem MUST be with the other ISP and nobody checks the patch cable bet

          • You have to admit, though, those other guys really are idiots.
    • It isn't really hard? Big job = lots of people involved.

  • by turkeydance ( 1266624 ) on Monday April 13, 2015 @08:06PM (#49466781)
    r u redi to rumble?
  • by labradore ( 26729 ) on Monday April 13, 2015 @08:38PM (#49466953)

    > There's a risk of regression when exposing the code to many more systems

    The risk of regression is due to refactoring, not due to testing. Ironic, given that the post cites de-obfuscation as a reason for doing this. Or perhaps our submitter just got an MBA and is learning to think and speak [] in management-ese [].

  • by m.dillon ( 147925 ) on Monday April 13, 2015 @10:55PM (#49467535) Homepage

    It's not a major refresh, only a modest one, and it doesn't really fix the readability issues (which would require a complete rewrite). Linux assembly is a mostly unreadable, badly formatted, macro-happy mess. The assembly in the BSDs is much more elegant and minimalistic.


    • by Steve Hamlin ( 29353 ) on Tuesday April 14, 2015 @10:55AM (#49470393) Homepage

      +5 Informative / Insightful for parent

      For background, the parent comment is Matthew Dillon, compiler and kernel hacker on Amiga/BSD/Linux and founder of DragonFly BSD (fork of FreeBSD). []

  • by PenguinJeff ( 1248208 ) on Tuesday April 14, 2015 @12:10AM (#49467791)
    The improved assembly code is what allows the Terminator to be so efficient a killing machine.
    • So when we get to kernel version 4.1.15, it will speak with an Austrian accent rather than Finnish?

      And of course, when we see the later T-1000 form a pointy sword from its liquid metal arm and kill young John Connor's foster father, it's further proof that there's still old cruft code in the future kernel, since it's just reproducing Linus' most famous gesture [].

"Buy land. They've stopped making it." -- Mark Twain