Codeslinger

From time to time, you might find yourself wondering just what it is I do all day. Edit, yes. But for a software company? What does that mean? Sometimes it means ads. Website content. An invite to an industry event. Or, for a treat, the company holiday card.

But this week . . . oh, this week . . . it means I had to slog through a 69-page white paper about network drivers. Please don't ask what they are. It's enough for you to know that the length of this document was equaled only by its boringness.

It's not the writer's fault, he's a smart guy and knows approximately one bazillion times more about network drivers than I do. But 69 consecutive pages of anything other than a novel would hurt my brain, and these particular pages said things like this:

"However, in this version of the network stack, the netBufPool back-end's netTupleGet() support was optimized to be significantly more efficient than doing separate allocations and joinings, as it only locks and unlocks interrupts one time."

Are they nouns? Are they verbs? Who can tell?

"Rather than using netTupleGet(), the driver may allocate a tuple by directly calling the linkBufPool's pMblkGetRtn() function pointer using the mBlkGet() macro defined in netBufLib.h."

Had enough? Well, please don't stop reading until you experience my favorite moment of all, the pièce de résistance, the denouement—

"The application reads the data within the zbuf as needed, and frees the zbuf when done with it, which in turn frees the underlying tuple chain back to the driver or stack pool from whence it came."

You see, even engineers have a little poetry hiding in their souls. You just have to tiptoe through the tuples to find it.

the wild zbuf in captivity