Facebook

David Woodhouse is one of the two first official 'embedded maintainers' for the mainline Linux kernel. David got involved in Linux while at the University of Cambridge. His first encounter with solid state storage was a summer vacation job on networking over power line, using Linux boxes for routing. It was part of the basis of what later became the MTD [Memory Technology Device] subsystem. Later David ended up working for Red Hat's engineering services division, doing board ports, drivers and other work. That's when JFFS2 was written, as part of a customer contract. After some 8 years at Red Hat, David joined the Intel Open Source Technology Center, a job that he can combine with his volunteered role as 'embedded maintainer'. Community interaction will continue to be part of his day job.

Dawn: What do you like about working in Intel's Open Source Technology Center?

David: The thing I enjoy most is the ability to work with the hardware developers.

Some of my favourite moments in software development have been when we've all been together in the same room, poking at something with an oscilloscope and working out what's going wrong -- then either myself or the hardware guys would fix something and we'd repeat the process.

Hardware and software don't exist in isolation; they depend heavily on each other and there's often too much of a disconnect between the developers of each. It's great to bring the two sides together.

Dawn: You did a session at the recent CELF Embedded Linux Conference about how embedded developers need to have more interaction with the greater Linux community. Why is this so important?

David: It's important for everyone, not just embedded developers -- it's just that embedded developers have traditionally been quite bad at it.

I can rant on this topic for hours -- and have been known to fly half-way round the world just to do so. But I'll try to keep it brief for now...

Linux development is a team effort. We work together to design and implement the best operating system we can. When developers work in isolation and present their work only as a fait accompli, they do themselves and the rest of the team a disservice.

By presenting their plans and then their work as early as possible, they can benefit from the knowledge and experience of other people, and by discussing our future requirements we can work together to create something that meets the needs of everyone.

In particular, if you do it right the first time, and get your work merged into the upstream kernel, you don't end up having to do it all again for your next product. Some people seem to need to learn this the hard way. Repeatedly, in some cases.

Dawn: I've read that you spend long periods of time languishing in the dark in front of a CRT intermingled with an unquenchable urge to climb mountains. Can you tell us about your favorite climbing adventure?

David: Heh, that's a fairly old description of my life -- I don't spend much time in front of CRTs these days. I do still live in the flattest part of the country and periodically have to submit to the urge to go walk up mountains though. Or skiing -- I seem to get to do that more than I do walking these days.