Structure vs purism ?

Dave Jones. (
Wed, 20 Jan 1999 14:34:57 +0000 ( )

-*Please excuse long post, I couldn't say this any shorter way*-

Just before 2.2.0pre8 became available, I picked up the book
"Linux Kernel Internals", in which the author writes the following..

"The Linux kernel is certainly not in every respect a good
model of structured programming. There are magic numbers in
the program text instead of constant declarations in header
files, inline expanded functions instead of function calls,
goto instructions instead of a simple break, assembler
instructions instead of C code and many other inelegancies.

Many of these distinctive features of unstructured programming,
however were deliberately included. Large parts of the kernel are
time critical; so the program code is optimized for good run-time
behavior rather than easy readability".

This book was written about kernel v1.2
Approx. four years later, and most of the facts in that last paragraph
remain true. I was shocked when I did the command..

rgrep goto *

Just under 1000 goto's. Some of which are trivial. Goto's to one-liners,
which are easily tidied. Other files are real snakes-nests. Following the
trail of goto's as they double back on themselves is no fun for the brain,
even less so for a CPU, as modern features such as branch prediction are
misused. (Remember the branch prediction tables are a set size, and can
only store results of a few jumps).

I had spent the last few days recoding some of the routines to use more
structured solutions. Immediately, the code became easier to read.
Spaghetti goto's were replaced with calls to functions/breaks/returns.
In some cases, I believe the code would have actually got faster, as there
was less jumping around (in some cases no change of program flow right up
until the return;) thus nullifying the 'speed critical' argument.

Gcc will generate the same 'short jmp' x86 instruction for a goto, or a
break; The only time code is generated differently is when a function is
created out of code which is goto'd from several places. This type of code
is quite spaghetti like, and a more structured approach can only generate
better code than this tangled mess of short jmp's. Even if extra functions
are created, if short enough gcc can be told to inline them, resulting in
almost-identical result to what we currently have, but with more readable
source code.

Then 2.2.0pre8 arrived, which had goto's in some places where there were
not before, whilst the average goto count per file remained roughly the

I began to wonder if I should bother trying to clean this stuff up
if it's going to get unfixed in each revision of the kernel. Some of the
routines are so intensely littered with goto's, that the restructuring
would almost constitute a complete rewrite. As we're so close to a 2.2.0
final, I don't think this would be a good idea. However it may be
preferable to start 2.3.x on a good footing with a clean source code.

The idea of goto's being a 'bad thing' is possibly the first thing that
gets taught on pretty much every programming course I've ever been on.
Some might argue, that this ideology is just for purists, but compilers
have become a lot more advanced. The use of constructs such as goto are
outdated crutches used by people too lazy to write a more structured

To end with a question :

Should I bring my patches for 2.2.0pre7 up to date?

Dave Jones.

| Dave 'Barc0de' Jones. (Paranoid wierdo noize making geek) |
| |
| |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at