LIRC - the Linux Infrared Remote Control project [LWN.net]

LIRC - the Linux Infrared Remote Control project

Posted Jan 11, 2007 12:54 UTC (Thu) by nim-nim (subscriber, #34454)
Parent article: LIRC - the Linux Infrared Remote Control project

My main beef with lirc is the kernel bits are not pushed Linus-side, which is only slightly less annoying and time-wasting than closed binary modules

I'm surprised LWN forgot to mention it.

to post comments

LIRC - the Linux Infrared Remote Control project

Posted Jan 11, 2007 13:31 UTC (Thu) by pbardet (guest, #22762) [Link] (2 responses)

If I remember correctly, Alsa had to wait until being 0.9XXX+ before being included in the kernel. I would assume it's normal to wait for a software to exit the pre 1.0 version to include it in an official kernel.

LIRC - the Linux Infrared Remote Control project

Posted Jan 11, 2007 14:08 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

No it's not.

Unclean code is frowned upon but merely experimental code that can be used to do things is OK (and lirc passed this stage years ago).

The restriction is on code quality, not feature-completeness (for example Xen is feature-complete but code is not in top shape, while kvm is a partial semi-experimental implementation with good coding. Guess which one is in Linus' kernels)

Xen vs KVM might not be the fairest example

Posted Jan 11, 2007 15:34 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

... one might argue that Xen is suffering from a little bit of "NIH" syndrome in the kernel development community. (Not invented here).

I'm not asserting that this *is* the case ... merely that Xen vs. KVM is not the best example to use when talking about the inclusion of lirc kernel code into the mainstream kernel sources.

I remember that the PCMCIA drivers were maintained out of tree for many ... many ... far too many years. I get the impression that this is comparable to the state of lirc.

So, who's going to rectify this? When?

JimD