This week's 30 Linux Kernel Developers in 30 Weeks profile goes in depth with Mauro Carvalho Chehab. As maintainer of the Linux kernel media susbsytem, Carvalho Chehab works from Brazil where he focuses as much time as he can on helping new developers learn how best to contribute and work with the community.
Mauro Carvalho Chehab - nick: mchehab
What role do you play in the community and/or what subsystem(s) do you work on?
I am the maintainer of the media subsystem at the Kernel. That includes drivers for remote controllers, webcams, audio/video stream capture, analog TV, digital TV and AM/FM receivers/transmitters.
I'm a main contributor of the EDAC subsystem. As such, I'm currently working on better integrating the several subsystems related to hardware error reports (EDAC, APEI GHES, MCE) in order to work together.
I'm also working on some related userspace tools, like xawtv, v4l-utils, edac-utils, and a few other tools.
Where do you get your paycheck?
In August, I celebrated four years at Red Hat. Before that, I used to maintain the media subsystem on my spare time, while working on something completely unrelated (my previous position was to plan and deploy telecommunications systems and telecommunications management network - worked as such on some large Brazilian wire and wireless carriers).
What part of the world do you live in? Why there?
I'm now living in the southwest region of Brazil. Before that, I was living in Brasilia. My wife, kids and I used to suffer a lot with the dry desert-like climate of Brasilia. So we've migrated to a nice city in the inner area of São Paulo's state, at the Paraiba River Valley, on a city with good infrastructure and good schools for the kids.
We're now close to a big city, São Paulo's (but not so close to suffer from the usual problems that all big cities have), as well as to some nice venues at the mountains and at the beach.
What are your favorite productivity tools for software development? What do you run on your desktop?
I run the usual tools: git, gcc, gmake, bash, perl, an emailer and a browser.
I don't care that much about the emailer, so I just use Thunderbird most of the time. Though, I also use pine, claws-mail and/or evolution, depending on my mood. As all folders are installed on a local imap server, the email client doesn't matter that much.
While I generally prefer to use text-mode tools, I'm not against using gui tools where it helps. So for file editing, I use nano most of the time. Yet, when I really need to do some complex things, kate is my choice.
I wrote several bash/perl scripts to help with my way of handling patches.
The distro I'm using currently is Fedora, as it offers everything I need. I'm generally running the very latest stable version of it, as I love to see new improvements on my desktop. Though, I don't appreciate that much when the features I use on some GUI interfaces are removed on a new version of the same application.
With regards to GUI, I use three monitors here, as I keep too many windows opened at the same time. Unfortunately, most GUIs don't support well more than one monitor. So I'm always trying a new one to see what works well with my environment (well, KDE 3 and GNOME 2 used to work properly, but they're gone from modern distros).
So I keep changing between xfce, lxce, KDE 4 and GNOME 3. Since Fedora 17, GNOME 3 almost works with several extensions enabled. So I'm currently trying to live in peace with GNOME 3, as, even running xfce/lxce, most applications will load GNOME 3 core anyway. So the memory footprint savings with xfce/lxce are generally lost, and some minor issues may arise by not having the GNOME 3 shell managing them.
How did you get involved in Linux kernel development?
I have a long history with Linux. The first Linux version I used was Slackware 0.97 with Kernel 1.0, which I installed to work as an Internet router (I was fortunate at the time to have an astounding 9,600 Kbps dedicated Internet link on my desk and wanted to share it with my pals at the office). I tried first to use an open source TCP/IP router, called KA9Q, but it was not stable on my environment, so a friend suggested me Linux instead.
Since them, I've installed Linux on my desktop and deployed Linux in several places in order to manage Plain Old Telephony Service central offices. During that time, using open source and doing internal development inside a telecommunications company was considered blasphemy, even when it was saving tens of millions of dollars per year with a Linux-based solution. So, I've experienced an increasing feeling that I should be giving back to the community due to the great services provided by open source software there.
My start as a Kernel hacker happened by accident. In 2005, I was thinking about working on a doctoral degree in Engineering. As my graduation and two under-graduation course theses were done at the Image Processing area, my plan was to work on writing some neat video codec. So, I bought a TV capture board that was supposed to work on Linux.
Unfortunately, the video standard used in Brazil (PAL/M) wasn't supported. Yet, everything for PAL/M seemed to be code there at the driver. Yet, the videos were displayed in black and white.
So I decided to fix it myself and submit the fix upstream. It took me about two weeks to work on this patch, re-reading old analog TV books to see the timing details of
several video standards and reading data sheets to know how to program the device. At the end of the day, the colors weren't working due to a 0.1% time shift at the part of the driver responsible for programming the video decoder sampling time. The net result was two lines of code patch ;)
At that time, Randy Dunlap and Andrew Morton helped me a lot to get this patch merged, giving me the proper directions on how to submit it at LKML. Nowadays, when I receive a patch from a new submitter, I remember the patience they had and I try to not be to grumpy with the submitter.
After the PAL/M fix, I found several other bugs that forced me to rewrite the tune module at the subsystem and several other parts inside the driver. Also, other developers asked me to submit their patches and later asked me to officially take the maintainers duty. As I didn't really know what that would mean to my life, I was dumb and brave enough to take it ;)
Some time later, I got surprised that something that started as a simple fix turned into a serious job. It was natural next move for me to give up my 20-year career in order to work with Linux and open source as my full time job.
What keeps you interested in it?
Each new driver I write is like generating a new son: seeing it take its first steps and then becoming useful to someone else is very exciting.
I also love to fix broken designs, to cleanup code and to help others contribute. The big success of open source and Linux is due to collaboration, and I'm proud to help with its success and to help users to have drivers for their devices on Linux.
What's the most amused you've ever been by the collaborative development process (flame war, silly code submission, amazing accomplishment)?
There's no one single amusing event. In general, it happens when I see new blood starting with simple patches and suddenly becoming active contributors.
It is also very nice when out-of-tree drivers get merged upstream. We had several success cases like that at the media subsystem: people that worked with their own pet project finally realize that merging the code back is good not only for them, but to everybody else who might be using their code. Merging those codes is not easy, as those developers in general complain about Linux coding style. But at the end of the day, their drivers tend to become better, as more people will review and submit fixes for the code.
What's your advice for developers who want to get involved?
Don't be afraid to submit patches; if there's something broken or that can be improved, please write a patch and submit it.
It is is very likely that people will give you bad comments on your first patch, saying that the patch is crappy and/or it doesn't follow the Linux coding style. So my second piece of advice is (quoting Galaxy Quest): "Never give up, never surrender!" Redo the patch until it fits. It may take a few rounds until it gets accepted, but you'll be learning in the process.
And my third piece of advice: Do not be intimidated by the English language! I know several people who were afraid of sending patches because they're not native English speakers. Patches are reviewed by the quality of the code, not by the vocabulary. Of course good descriptions are part of it, but if the language is not 100% perfect, that can also be fixed. Some reviewers, including me, have the habit of fixing messy comments when patches aren't properly described or when it is noticed that the patch writer have some troubles with the language.
Reading the documentation at Documentation/ directory before submitting a patch helps a lot to have a better patches.
Greg Kroah-Hartman's Linux Driver Project is a good starting point for those who want to get involved.
What do you listen to when you code?
The sounds of silence ;) I generally prefer to not be disturbed by any sound when coding.
When I'm doing more routine work, I sometimes listen to some good music. I'm very eclectic when listening: I like classics, rock, country, international music, opera, opera rock, and, of course, Brazilian styles (Samba, Bossa nova, Chorinho, old guard, new guard, Tropicalia, Sertaneja, Brasilia's rock, Brazilian rock, etc). I also like to listen to new voices like Adele.
Typically, at the end of a working day, or when I'm over-stressed or need to wait for a timely compilation, I take a guitar (or a bass guitar) and I try to play
a song. That's a good way to get rid of the daily stress and to give my brain some time and oxygen to think on how to solve some complex issue.
What mailing list or IRC channel will people find you hanging out at? What conference(s)?
I generally don't do too much IRC nowadays, as it can be very distracting. So I keep a bot always connected there and from time to time I take a look on the backlogs, sometimes discussing development/patch merging tasks there.
With regards to conferences, it varies. Since 2008, we do at least one annual conference for the media subsystem. I'm generally there. I'm generally at the Linux Kernel Summit and the companion conference(s).