30 Linux Kernel Developers in 30 Weeks: Jiří Kosina

2620

This week we talk to Jiří Kosina in our 30 Linux Kernel Developers in 30 Weeks series. He tells why Linux is like a “Who Done It” story and also explains why working on Linux to be cool isn’t enough.

jikosName

Jiří Kosina. But since the ‘ř’ letter is impossible to pronounce for almost anyone outside the Czech Republic, I usually end up using Jiri.

What role do you play in the community and/or what subsystem(s) do you work on?

The MAINTAINERS file lists me as a responsible person for multiple subsystems or kernel areas. The more interesting ones, in decreasing order of relevance:

– I am maintaining the HID (human interface devices) subsystem. This means handling a very wide variety of hardware, starting with USB/Bluetooth mic/keyboards/joysticks, but also including multitouch devices (where Benjamin Tissoires is doing most of the work). Other interesting bits currently appearing on the horizon are HID over I2C, support for HID sensors, etc.

– Address space layout randomization for userspace executables. A huge part of that code was originally extracted from ExecShield, but I reworked it multiple times, had it merged into Linus’ tree, and fixed all the bugs that kept coming over the years. And there were some quite obscure ones, indeed, mostly related to libc5-based binaries (yes, there are still people out there running those on 3.x kernels), prehistoric emacs versions assuming that address of last global declared variable marks the beginning of brk() heap, etc. Very odd experience.

– APM support (for those who are not old enough to remember — yes, that is the thing we used before ACPI has been invented). I took this over because I still own hardware that I try to run up-to-date kernels on, and it’s APM-only. It’s been pretty quiet though; no one seems to care deeply (except for CPU idle support being deprecated and un-deprecated over and over).

– Floppy driver. I acquired this only recently. I had to fight the current maintainer to the death in the Thunderdome, and … well actually the driver has been mostly unmaintained for very long time, and it turned out that it’s horribly racy. Funny thing is that it always used to be, but no one cared — the real floppy hardware is just too slow to trigger any of the races in the code. But those who are brave enough to virtualize floppy drive will start hitting all those all of a sudden, as the virtualized floppy device is damn fast. After having fixed this, the driver just landed on my plate. Oh well, that’s not the career I have always been dreaming for.

– Trivial tree. Basically collecting trivial patches that no one else would care for, and sending them to Linus once a merge window.

Where do you get your paycheck?

SUSE. I work as a leader of “Core kernel” team in SUSE Labs department and am a responsible maintainer of kernels that are being shipped in SUSE Linux Enterprise products.

What part of the world do you live in? Why there?

Prague, Czech Republic. I have been born here, and except for an interlude when I was working at CERN, I never really had a reason to live anywhere else.

What are your favorite productivity tools for software development? What do you run on your desktop?

I used to use KDE since its very early times. But KDE4 was an ultimate critical point; I just couldn’t resist moving to something magnitudes more lightweight. So I am currently running icewm, with a plenty of xterms in it, vim, gcc, git, quilt, (al)pine, browser, some random IM client, twinkle for voip, mplayer … and that’s pretty much it.

How did you get involved in Linux kernel development?

We were setting up an Internet router (using dial-in 9k6bps modem line of course) when attending high-school some time in 1996, and there was something that was broken — I believe it was a deadlock in a network card driver that was blocking us. I realized that I might actually be able to obtain source code somewhere and try to figure out what’s happening. It took me several sleepless weeks before I understood everything but was able to fix it in the end … only to find out that it was fixed already in 2.0.17 or something. But it was still an amazing experience.

What keeps you interested in it?

The unique combination of the highly technical and highly social aspects of it.

What’s the most amused you’ve ever been by the collaborative development process (flame war, silly code submission, amazing accomplishment)?

I like the debugging-over-email sessions. Trying to figure out why the system of the person reporting the bug behaves the way it does, putting all the pieces of information together, trying to come up with smart ways how to instrument the code to know a little bit better what is happening. It’s like reading a dramatic whodunit story, with a bonus that you can actually participate in it.

What’s your advice for developers who want to get involved?

If you need to ask questions such as – “I want to be a kernel developer, because I think it’s cool, what should I work on?” – start by changing your mindset first.

I am pretty sure there are many things that you detest about Linux, so why not just start fixing those? Isn’t your home fileserver just too slow? Isn’t your audio skipping when you are doing some I/O-instenstive work? Don’t you hate how your OOM killer always decides to kill your editor with an important love letter?

Really, my basic advice would be — stop ignoring the tiny little things that are annoying you “just a little bit,” and start working on fixing those. The rest will come.

What do you listen to when you code?

When working on something that my brain is considering to be a really tough problem, I need silence. Otherwise I have quite a broad music taste, spanning from classical music (mostly Mozart), through rock to punk.

What mailing list or IRC channel will people find you hanging out at? What conference(s)?

Community mailing lists: mostly LKML and linux-input, more sparsely on usb-devel.

IRC: /whois jikos

Conferences: Kernel Summit + the co-located conference, and a random selection of other kernel-related conferences, not really being consistent year over year.