Muli Ben-Yehuda's journal

Compare, contrast, weep:

 
((bar*)foo->bar)->gar->member = ((adapter*)(ptr + 4))->sequence_number++; 

(Real code, struct and member names changed to protect the guilty)

With:

 
struct bar* bar = foo->bar; 
struct gar* gar = bar->gar;

struct adapter* adapter = (ptr + 4);

gar->member = adapter->sequence_number++; 

I just spent a couple of minutes making sure that the second version is functionally equivalent to the first, and I’m still not sure. Think about it – a couple of minutes for ONE line of code. Code should be written for people first, compilers second. Say no to gratuitous obfuscation, say yes to intermediate variables!

There’s a line of thought amongst programmers who do not understand what portability means that simply wrapping up any system service in a MACRO is enough. printf() becomes PRINTF(), sleep() becomes SLEEP(), etc, etc, ad nauseam. The fallacy here, of course, is that they assume that the name might change, but the interface won’t, which is dead wrong. Name changes are the least of your worries. It’s interface changes that you should be concerned about, and your “portability layer” must present a common, unified interface, not just “the interface of whichever platform this code ran on first”. Furrfu!

I’m too lazy to write the same thing twice, so I’ll just paraphrase from an email I sent after the event:

“The Kernel Hacking talk today at TAU went pretty well. There were 25-30 students, 5 or so were “free listeners”, and the rest students taking the workshop. No one fell asleep and almost everyone stayed through the entire three hours. I had a a pretty bad start due to not realizing the first two subjects (kernel introduction and source layout and kernel compilation) are pretty darn boring without any motivation, but once we hit the second hour with “writing kernel modules”, things definitely picked up. People were interested in all aspects of kernel development, both the technical (how to write the code) and the sociological (how to get it accepted). Also, several people took notes when I talked about syscalltrack and talked to me about it after the lecture. I guess now we need to wait and see if anything comes out of it :-)”

This morning I woke up at 04:30 AM after crashing last night at 09:00 PM, and finally added a bibliography slide to each of the subjects, with links to the prominent source of information on that subject. Also added a slide on mknod(1) to the kernel module talk. Updated slides available on mulix.org/lectures.html.