Linux Getting Extensive x86 Assembly Code Refresh

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.

Comments

Debt

[Ducho_CWB]

Technical Debt haunts you.

Re:Debt

[Darinbob]

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.

Can we be sure there are no exploits?

[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?

Re:Can we be sure there are no exploits?

[Lunix Nutcase]

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

Re:Can we be sure there are no exploits?

[Rigel47]

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:If It Ain't Broke, Don't Fix It!

[Anonymous Coward]

if they want to audit those stale old things for correctness and performance, and make them more readable for future generations, and
do the testing and review to make sure they haven't fucked them up

then good for them. i mean really good for them.

any code - especially the kernel - isn't a concrete artifact, its a process. an organism.

heathy organisms eliminate their wastes

and a 2% performance bump in system call overhead isn't anything to sneeze at

Re:opportunity for backdoors?

[EzInKy]

Who can sight read assembly anymore?

Everybody who is interested in "How Things Work" can read assemblly code. Those who depend on hopes and prayers do not.

It's only a modest refresh

[m.dillon]

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.

-Matt

Re:Should be micro kernel

[Guy Harris]

I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.

I'd have to see that interview to believe that's exactly what he said. In this essay by him, he says

With the 2.0 kernel Linux really grew up a lot. This was the point that we added loadable kernel modules. This obviously improved modularity by making an explicit structure for writing modules. Programmers could work on different modules without risk of interference. I could keep control over what was written into the kernel proper. So once again managing people and managing code led to the same design decision. To keep the number of people working on Linux coordinated, we needed something like kernel modules. But from a design point of view, it was also the right thing to do.

but doesn't at all tie that to microkernels.

Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 and AIX 3.0 in the early 1990's. I'm not sure they were introduced to compete with microkernels.

Re:Wouldn't a re-write be more fruitful?

[Hognoxious]

I don't really know why.

Users will say "But it works, we don't want to change waaagh scary" while simultaneously reporting 237 bugs all of which are OMG critical. Management will assume that it's cheaper, because existing stuff is already there so it's wasteful not to use it.

Now it's true that once a load of crufty business rules have built up with 17 levels of nested conditionals it can be risky to try and replicate it for fear of missing some obscure case that's bound to occur at an inconvenient time for a key customer. There's no documentation, of course. Or if there is it's the source code, six revisions behind, pasted into a word document with three screenshots taken as BMPs so the whole thing is 1.5G. This alone can make you say "sod it".

I can't find the correct phrase but maybe it's just a false analogy with physical things. Like reusing wood from an old shed to build a deck possibly is cheaper.

Re:If It Ain't Broke, Don't Fix It!

[Gavagai80]

You're operating on the mistaken assumption that code that works now will always work and never need to be modified. You can't leave anything but the simplest things alone forever, because changes to the context/world will eventually require changes to it. If it's spaghetti code, that's going to be causing future bugs that are going to be non-obvious and difficult to discover.

Re:If It Ain't Broke, Don't Fix It!

[Troed]

I am "in Software" since ~25 years. I also hold a degree as a Software Engineer.

People who obsess about rewriting old code just because it's old tend to forget that in that old code are many bug fixes for edge cases found over the years. It was well documented and part of my education to know and understand that rewriting often caused those same bugs to surface again.

Best practice is to run both the old and new software in tandem for a while and verify the results. In reality no organization besides NASA will do that.

Belittling is the way to go!

[Anonymous Coward]

The best way to make yourself big and brilliant is to take someone elses excellent code that you could never write, go through it and implement their logic in "new" code claiming that their "spaghetti garbage" has now been fixed by you even though you did little more than a lint tool would.

Claiming that the work of others, that you build upon and without which you would be fumbling in the dark, is garbage is bad form.