of quality in the code. Read the descriptive comments
for each element and the indication of where the proper
types can be found, as in the case of pmd_cputype being
from enum pmc_cputtype.
One final comment on this file. Note that the programmer is writing objects in C. Operating-system kernels
and other low-level bits of code are still written in C,
and though there are plenty of examples now of people
trying to think differently in this respect (such as Apple’s
Mac OS X drivers being written in C++), low-level code
will continue to be written in C. That does not mean
programmers should stop using the lessons they learned
about data encapsulation, but rather that it is important
to do the right thing when possible. The structure listed
here is an object. It has data and methods to act upon it.
The BSD kernels have used this methodology for 20-plus
years at this point, and it’s a lesson that should be learned
and remembered by others.
These are just a few examples from this code, but in
file after file I have found the same level of quality, the
same beautiful code. If you’re truly interested in seeing
what good code looks like, then I recommend you read
the code yourself. If any place is a “happy place,” it is in
code such as this.
What do you mean by “formerly known as trial and
error”!?! Are you telling me that this fad has died? As far
as I can tell, it’s alive and well, though perhaps many of
its practitioners don’t actually know their intellectual parentage. Actually, I suspect most of its practitioners can’t
spell intellectual parentage.
Alas, it is often the case that a piece of good advice is
taken too far and becomes, for a time, a mantra. Any-
thing repeated often enough seems to become truth.
Mr. Brooks’s advice, as I’m sure you know, was meant
to overcome the “it must be perfect” mantra that is all
too prevalent in computer science. The idea that you
can know everything in the design stage is a fallacy that
I think started with the mathematicians, who were the
world’s first programmers. If you spend your days looking
at symbols on paper, and then only occasionally have
to build those symbols into working systems, you rarely
come to appreciate what happens when the beauty of
your system meets the ugly reality that is hardware.
From that starting point, it’s easy to see how program-
mers of the 1950s and 1960s would want to write every-
thing down first. The problem is that a piece of paper
is a very poor substitute for a computer. Paper doesn’t
KV have odd delays introduced by the speed of electrons
in copper, the length of wires, or the speed of the drum
(now disk, soon to be flash). Thus, it made perfect sense
at the time to admonish people just to build the damned
thing, no matter what it was, and then to take the lessons
learned from the prototype and integrate them into the
The increasing speeds of computers since that advice
was first given have allowed people to build bigger, faster,
and certainly more prototypes in the same amount of
time that they could have built a single system in the
past. The sufferers of prototypitis are really just chicken.
Not putting a line in the sand is a sign of cowardice on
the part of the engineer or team. “This is just a prototype”
is too often used as an excuse to avoid looking at the hard
problems in a system’s design. In a way, such prototyping
has become the exact opposite of what Mr. Brooks was
trying to do. The point of a prototype is to find out where
the hard problems are, and once they are identified, to
make it possible to finish the whole system. It is not to
give the marketing department something pretty to show
potential customers—that’s what paper napkins and lots
of whiskey are for.
P.S. Complete code cross-references for many operating-system kernels, including FreeBSD, can be found at
http://fxr.watson.org/, and the code you’re looking for
can be found at http://fxr.watson.org/fxr/source/dev/
hwpmc/. A similar set of cross-references can be found
on the codespelunking site: http://www.codespelunking.
In his book The Mythical Man-Month, Frederick P. Brooks
admonishes us with grandfatherly patience to plan to
build a prototype—and to throw it away. You will, anyway.
At one point this resulted in a fad-of-the-year called
prototyping (the programming methodology formerly
known as trial and error), demonstrating that too little
and too much are equally as bad.
What is your view of creating prototypes, and, particularly, how faithful does a prototype need to be to resolve
the really tricky details, as opposed to just enabling the
marketing department to get screen shots so they can
strut the stuff?
An (A)typical Engineer