30 Linux Kernel Developers in 30 Weeks: Paul Mundt

In this week's 30 Kernel Developers in 30 Weeks profile, we talk to Paul Mundt, who works on the SuperH architecture and core parts of the AMR-based SH/R-mobile platforms. He shares a variety of stories from his nearly 20 years of experience working on the kernel, including one that proves collaboration never sleeps, even when you do during an inter-contentinetal flight.  

Name

Paul Mundt

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

I primarily look after the SuperH architecture (and by proxy, core parts of the ARM-based SH/R-Mobile platforms), but that tends to entail wearing quite a few different hats. In the past it was mostly an effort to keep generic code from breaking my platforms (a struggle that persists to this day), but as embedded gradually ceased being a second-class citizen in the kernel it's been much easier to focus time on repurposing existing infrastructure for additional use cases.

Outside of my architecture maintainer role, my time is mostly split between memory management (especially MMU-less systems, NUMA support, proliferation of large TLBs, etc.), clocks/general timekeeping, and IRQ management. Lately I've been working on making irqdomains more useful (particularly for the non-DT crowd) and extending clockevents to manage unused timer channels more effectively.

In the past I also looked after the framebuffer subsystem for a period of time, but that work has since changed hands as I was unable to give it the amount of time it needed for full-time maintenance.

Where do you get your paycheck?

Renesas Electronics

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

Tokyo, Japan. I became disillusioned with Silicon Valley a long time ago and haven't seen any compelling reason to return. After country hopping for a bit, Japan has been home for more than six years and suits me pretty well. The fact that the bulk of the country is mountainous also provides me with more than enough avenues for keeping busy outside of work.

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

I suppose that would be a combination of fbcon, vim, and mutt. It's how I've always worked (albeit without fbcon in the pre-2.1 days). I've never been able to get any serious work done in a desktop environment, so I avoid them as much as possible. That being said, on the occasion that I need to browse a site that doesn't render in lynx, read some document that has been provided in a nonsensical format, or finding myself spending an inordinate amount of time with Japanese input, I'll grudgingly run fvwm2. Text has always been my preferred method of working.

How did you get involved in Linux kernel development?

I came to Linux pretty late, around 1996 or thereabouts. I started out fairly typically, a pile of random ISA cards where support was either lacking or completely broken. The first project was getting DMA working on a 3c501, or something like, that in some random 2.0 kernel. It was long ago enough that I don't remember the particulars, but it certainly wasn't pretty. When the framebuffer subsystem was merged in late 2.1.x I started spending time there and then gradually transitioned in to architecture work (MIPS at first, then SuperH via reverse engineering of the Dreamcast).

What keeps you interested in it?

The constant evolution. Evolving existing code to support new requirements while co-existing with the old. Being able to revisit a bit of code you wrote over a decade ago for dealing with a particular problem after finding out that you suddenly have a cleaner and more efficient way to deal with it (assuming you can remember what you were thinking), etc.

It's also interesting to see ways in which people are utilizing the kernel that you hadn't previously considered, particularly as it often provides you with a completely different viewpoint or direction for existing infrastructure.

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

You'll find that there a lot of people with interest in some very niche areas who can get quite territorial, which you can often manipulate for your own benefit: by posting a patch that both solves a particular problem while simultaneously offending their sensibilities sufficiently that they're immediately spurred in to action to solve it much more effectively for you.

I was working on a particular problem where I hit a limitation of the bitmap API where my desired bitmap size exceeded the number of bits, a case that had been crafted to trigger a bug with a helpful note that whoever hits it first gets to code it. I set about addressing this with a crude algorithm for tracking spanned longs (posthumously dubbed the Mundt multiword extension) while on a long-haul flight home from Seoul. As internet access was spotty at best, I spent more time napping and tending to my drink than actively monitoring the list traffic, but by the time we touched down the code had already been rewritten, optimized, and sent off to Linus for merging.

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

Don't get trapped in walled gardens.

The kernel and the people working on it have weathered many vendors with their own agendas and will continue to do so for the foreseeable future. Unless you particularly want to work for a given vendor, don't get distracted by the short term and get sucked in to a vendor tree because it happens to be easiest in terms of hardware availability (this also applies to industry forums that allege to have an interest in solving problems generically without attempting to engage with upstream during development). As many companies have overlapping interests for the kernel, kernel hackers are afforded a certain level of autonomy -- something that is not worth ceding for what will be another in a long line of abandoned initiatives in a few years time.

While the barrier to entry for supporting new hardware can be quite high, it's fairly straightforward to find an area that you're interested in and find things you are interested in changing. Ultimately it comes down to scratching an itch, which is something you are unlikely to experience with trivial or mechanical churn. You'll have more than enough help along the way, so long as you're willing to put in the effort and are attempting to make meaningful changes. Beyond that, everyone gets rebuffed from time to time regardless of whether they've been working on the kernel for 15 minutes or 15 years.

No kernel hacker that I can think of started out making whitespace or spelling changes, and that also seems unlikely to change. If you're trying to make a name for yourself in the kernel community, you ideally want it to be a positive one rather than a pejorative.

What do you listen to when you code?

It varies. I generally prefer quiet, but in an office environment that's not always possible, so anything that acts as a filter for more distracting background noise is fine.

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

For mailing lists, the usual vger set. linux-kernel, linux-arch, and for issues pertaining to my architecture, linux-sh.

I generally avoid everything but kernel summit, but I'll usually give a talk once a year or so depending on what I happen to be working on. If I do make it to another conference, I usually skip the talks and stick with hallway discussions.