Kernel Labs

After many years of the original V4L API being marked as deprecated, it finally went away in 2.6.38. This is one of those cases where the kernel developers concluded that V4L2 has been the standard for years, that V4L1 has been dead for a long while and it was finally safe to completely remove the support.

Except nobody remembered to tell the application developers. Essentially all the apps out there still relied on V4L headers being present, and in some cases the applications were making older V4L calls which did not have V4L2 equivalents.

KernelLabs made code changes and released a tvtime build a few months ago with V4L support removed to address this issue, and Mauro Carvalho Chehab did some work on Xawtv to accomplish the same.

The reason I bring this up is because Ubuntu 11.04 was released a few days ago, which contains kernel 2.6.38, and the net result was basically one of the more popular distributions shipping a version of MythTV that didn’t include any support for analog tuners.

This is bad. While not always logged in, I do read the #mythtv-users IRC channel log on a daily basis, and there have been a huge number of cases that boil down to “I upgraded to the latest version and now my tuners stopped working.” This sort of thing creates lots of work for the advanced users who answer questions in the channel, and it damages the reputation of both MythTV and the Linux Kernel when so many users upgrade to the next major release and the net effect is that their card stops working.

Now, as kernel developers we could argue that it’s our prerogative to remove an API that was deprecated almost a decade ago. And we can argue that it’s the application developers’ responsibility to follow suit and make sure that they make the code changes necessary to work with current kernels.

It’s hard not to look at this situation though and say, “Wow, we did a crappy job here.” This is one of those cases where everybody is so tunnel-visioned on their individual part that nobody takes a step back and looks at the big picture. Or else somebody might have noticed that the latest version of the most popular distribution falls flat on its face when users try to use it.

Personally, as a developer who takes pride in my work I’m pretty embarrassed by this. Perhaps the real problem is that some of the other developers are not embarrassed enough. I often find myself comparing the development model I use for LinuxTV to the one I do at my day job. At my day job, we have some very strict rules that say things like:

“The mainline code must *always* compile successfully on all supported targets.”

It’s a basic measure of quality – does your code build? If a new employee checks in something that breaks the build, they get some gentle instruction on the policy. If you’ve been there a while, you get a reminder/warning. If you are a repeat offender, it’s pretty clear you don’t care about quality and you don’t end up working here for very long.

Not to turn this into a rant on quality in general, but anybody care to guess how many times I’ve tried to compile the current “media_build” tree only to find it doesn’t build on the most popular distribution out there with a current shipping kernel?

My suspicion is only when there are enough blunders like the one above will we (the LinuxTV developers) start to take quality seriously. I recognize that’s a controversial assertion to make, which will like generate responses along the lines of “You’re wrong! Of course we care about quality”. To which I can only respond, “Look at the build failure rates. Look at Hans’s daily report on build success over the last 12 months. Look at the Sparse results. Look at the kernel.org Bugzilla. Look at LaunchPad. Look at the forums and IRC channels.”

Ok, I failed a bit. That did turn into a general rant on LinuxTV quality.