Muli Ben-Yehuda's journal

Hackers and Painters, by Paul Graham.

(via lemonodor.com)

– school – study every day, improve my GPA.
– kernel – more hacking, more significant hacking.
– work – switch projects. Work with people whose mind set is similar to mine, on a challenging kernel project.
– self – resume working out seriously, lose weight and start practicing martial arts again. Take my body to the limit of its capabilities, and push it further every day.
– life – make ladypine happy(ier).

Quite a list, me’thinks. Time to get started.

Last week, the team at work went out to celebrate our first successful delivery. We had a good lunch at El-Gaucho, a South American restaurant, courtesy of IBM, and good times were had by all.

However, I couldn’t help noticing that we didn’t once discuss “geeky subjects”. Computers, computer science, hacking, free software, commercial software, math, physics, programming or any other subject of their ilk that usually comes up when I talk with friends. Instead, we talked about people’s children, and where we grew up, and what we did before coming to work for IBM, and far away places we’ve been to, and the quality of the food, and various other subjects you might expect a group of co-workers to discuss, but would never hint that they were working for IBM research.

I have a hard time articulating exactly why this bothers me. I think it boils down to the fact that it makes it impossible for me to ignore the major difference between me and my co-workers, and thus makes me feel an outsider: I consider programming something I love, and a job second. I don’t think I can say this about any of my current team-mates (but would love to be proven wrong!). It’s not my “vocation”, I can’t even say it’s a hobby. It’s just what I do.

I’ve been fortunate enough to work closely together with people who feel the same way as I do. I hope to be in that position again soon.

Addendum: when I told ladypine about lunch and my observation mentioned above, she told me to stop being so one-dimensional, and that people usually try to avoid talking about work during lunch. She’s right, but this is precisely where she’s wrong, too – it’s not work to me. It’s what I do. What I am?

Two patches, sent on Thursday:

– an update to the trident humongopatch, splitting it into indentation and everything else. Will probably show up in the next -mm kernel, and then in 2.6 vanilla when akpm decides to send it on.

– a patch to support chaining of skb destructors. Only one comment so far, suggesting some optimizations I can do and one trivial fix. No word from the networking guys. I’ll wait a few days and then post an updated version, CC’d to them explicitly. I want comments, damnit! even if it’s “dude, you suck”.

Now to finish the dishes, and onwards to the next entry…

So many things I want to say, and the words just don’t come out. Let’s take it one at a time, ok? first I’ll finish doing the dishes, and then I’ll start writing. Be back in a bit.

Finished the trident TODO by lunchtime today. Patch sent.

Update: whee, Linus responds! (and is 100% correct, as usual).

Finding a bug in your Linux driver via a paper posted on research.microsoft.com hurts my pride. Macros that return are EVIL, damnit!

edit: obviously, I’ve fixed it. I’ll send the patch to Andrew tonight after verifying that it still works.

Talking about signals in Linux sysprogramming class now. trident TODO for today:

– prog_dmabuf takes a rec parameter, make it an ENUM or DEFINE, write two wrappers around it for record / playback.

– SNDCTL_DSP_GETBLKSIZE should probably ‘break’ after checking both files. Verify that other OSS sound drivers behave this way.

– remove the lock_kernel() calls from trident_mmap(), trident_release(). Figure out what it (used to) protect and verify that it’s protected.

– fix the ugly mapped = … line in trident_ioctl()

– verify that the order of cleanup in trident_remove is correct and we can’t take an interrupt when we’re no longer ready to handle it

– in trident_init_module, do we need to unregister a pci driver after registration failed? current code does, verify.

The trident cleanup patch is up. After I got it to compile, there was a nasty buglet were I reworked the error path cleanup in trident_probe(), and ended up doing the cleanup even if the function was successful. Oops. Then, once I got that fixed, playing my test mp3, Abba’s Gimme Gimme, started stuttering. Since I couldn’t figure out why it was happening by just looking at the code, I started unrolling changes, and playing the song again after each change. I must’ve listened to it 50 times by the time I found out the culprit… Abba – it’s not just a band, it’s an occupational hazard of sound drivers developers!

The first day of the Linux sysprogramming class ended up being more interesting than I expected. I used the boring bits to hack on trident, and did a bunch of cleanups I’ve been meaning to do for ages (lock_set_fmt, a macro, was calling return if taking the lock failed. Ugh). I have more plans for tomorrow’s boring parts, but I’ll put up the interim patch in a bit after verifying that it works. It’s currently compiling.

I put up the util-linux tcp-udp nfs mount ordering patch. This patch gives the user greater control over which protocol (TCP or UDP) to use when contacting the NFS server, and whether to fallback to the other one. It’s a bit ugly (mostly because of nfsmount’s ugliness), and I’m waiting to hear what aeb, the maintainer, has to say. While putting it up, I gave the website and especially the CV a much-needed cleanup.