The Great IRQ Debate in the Linux kernel

We interrupt our normal kernel hacking in order to bring you this special report on an outbreak of IRQ warfare. OK, wait. I just made that up as an example of what happens when a device on your PC wants the processor, in hardware terms, or the kernel, from a software point of view, to do something. To signal the processor that it needs something done, the device turns on the appropriate IRQ, short for Interrupt ReQuest. The kernel takes care of business by satisfying the request, then turns the IRQ off again.

There has been a lot of talk lately on the Linux Kernel Mailing List (LKML) about allowing the devices themselves to control turning the IRQ off. Those who want to make it easier for closed source drivers to interact with the kernel would like to have that capability. Torvalds is firmly against it. It’s the binary blob versus the GPL all over again, but along different fault lines. For some the debate is technical, for others, it is philosophical. So it goes in the open source/free software community.

Debate flared up around a patch submitted to the 2.6.19 version of the kernel by Greg Kroah-Hartman, a longtime SUSE kernel hacker. Torvalds rejected the patch in his version, although it has been in Andrew Morton’s version of the kernel tree for a while now.

Torvalds explained his rejection by stating:

Please remove.

YOU CANNOT DO IRQ’S BY LETTING USER SPACE SORT IT OUT!

It’s really that easy. The irq handler has to be _entirely_ in kernel
space. No user-space ass-hattery here.

Linus expanded on his view in a later email message, saying, “I’m not violently opposed to something like this in practice (we’ve already allowed it for USB devices), but there definitely needs to be a real reason that helps _us_, not just some ass-hat vendor that looks for a way to avoid open-sourcing their driver.”

Based on Torvalds’ rejection and his request for real-world examples of the need for it, Kroah-Hartman wrote a message to the mailing list stating:

A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.

Right now the UIO core is working and in the -mm releases. It’s been
rewritten from the last time patches were posted to LKML and is much
simpler. It also includes full documentation and two example drivers
and two example userspace programs that test those drivers.

But in order to get this core into the kernel tree, we need to have some
“real” drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.

If no such drivers appear, then there is a very slim chance that this
interface will be accepted into the tree.

The debate has since spilled over into a larger issue, binary blobs versus the GPL. The ensuing discussion on the mailing list included a suggestion to purge the kernel of binary blobs entirely, by issuing a notice that in one year’s time they would no longer be allowed — the thinking being that one year would give the developers of the binary blobs time to develop a GPL-friendly device driver. The popular closed source Nvidia driver which provides Linux users with the full range of 3-D graphics Nvidia cards are capable of is an example of one such blob.

As Alan Cox noted in the discussion, it is not Torvalds’ decision alone to make. Torvalds’ opinion, however, probably carries more weight than anyone else’s, and Torvalds’ opinion distances him once more from that of the FSF. Torvalds challenged the companies backing the major commercial distributions to make such a change to their own tree first, not to his, when he wrote:

On Wed, 13 Dec 2006, Greg KH wrote:
>

> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright. Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.

Btw, I really think this is shortsighted.

It will only result in _exactly_ the crap we were just trying to avoid,
namely stupid “shell game” drivers that don’t actually help anything at
all, and move code into user space instead.

What was the point again?

Was the point to alienate people by showing how we’re less about the
technology than about licenses?

Was the point to show that we think we can extend our reach past derived
work boundaries by just saying so?

The silly thing is, the people who tend to push most for this are the
exact SAME people who say that the RIAA etc should not be able to tell
people what to do with the music copyrights that they own, and that the
DMCA is bad because it puts technical limits over the rights expressly
granted by copyright law.

Doesn’t anybody else see that as being hypocritical?

So it’s ok when we do it, but bad when other people do it? Somehow I’m not
surprised, but I still think it’s sad how you guys are showing a marked
two-facedness about this.

The fact is, the reason I don’t think we should force the issue is very
simple: copyright law is simply _better_off_ when you honor the admittedly
gray issue of “derived work”. It’s gray. It’s not black-and-white. But
being gray is _good_. Putting artificial black-and-white technical
counter-measures is actually bad. It’s bad when the RIAA does it, it’s bad
when anybody else does it.

If a module arguably isn’t a derived work, we simply shouldn’t try to say
that its authors have to conform to our worldview.

We should make decisions on TECHNICAL MERIT. And this one is clearly being
pushed on anything but.

I happen to believe that there shouldn’t be technical measures that keep
me from watching my DVD or listening to my music on whatever device I damn
well please. Fair use, man. But it should go the other way too: we should
not try to assert _our_ copyright rules on other peoples code that wasn’t
derived from ours, or assert _our_ technical measures that keep people
from combining things their way.

If people take our code, they’d better behave according to our rules. But
we shouldn’t have to behave according to the RIAA rules just because we
_listen_ to their music. Similarly, nobody should be forced to behave
according to our rules just because they _use_ our system.

There’s a big difference between “copy” and “use”. It’s exactly the same
issue whether it’s music or code. You can’t re-distribute other peoples
music (becuase it’s _their_ copyright), but they shouldn’t put limits on
how you personally _use_ it (because it’s _your_ life).

Same goes for code. Copyright is about _distribution_, not about use. We
shouldn’t limit how people use the code.

Oh, well. I realize nobody is likely going to listen to me, and everybody
has their opinion set in stone.

That said, I’m going to suggest that you people talk to your COMPANY
LAWYERS on this, and I’m personally not going to merge that particular
code unless you can convince the people you work for to merge it first.

In other words, you guys know my stance. I’ll not fight the combined
opinion of other kernel developers, but I sure as hell won’t be the first
to merge this, and I sure as hell won’t have _my_ tree be the one that
causes this to happen.

So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
first. This is not something where we use my tree as a way to get it to
other trees. This is something where the push had better come from the
other direction.

Because I think it’s stupid. So use somebody else than me to push your
political agendas, please.

Linus

And here you thought that getting the code right was the only thing the kernel hackers ever thought of.