* Package name    : irda-dkms
  Version         : 0.1
* URL             : https://github.com/cschramm/irda
* License         : GPL
  Programming Lang: C
  Description     : IrDA subsystem and device drivers

The IrDA subsystem and device drivers got moved to staging and scheduled for
removal upstream in Linux 4.14 [1] and consequently disabled in the Debian
builds [2].

[1] https://lkml.org/lkml/2017/8/27/126
[2] https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=d12b3a11b2800489cde0be2d74872af04b5b8f36

As I personally do have a use case for IrDA and am sure that I am not the only
one, I moved the code (from 4.15; not compatible to 4.14!) into a GitHub
repository [3], converted the build system to Kbuild files, and added a DKMS
configuration and a Travis CI configuration to check the build with current
kernel releases.

[3] https://github.com/cschramm/irda

I already prepared the packaging files. See [4] for copyright and license.

[4] https://github.com/cschramm/irda/blob/debian/debian/copyright

Christopher Schramm <debian@cschramm.eu> writes:

Why not raise your hand and offer to maintain IrDA in mainline instead?
The problems causing it to be shceduled for removal will not be
magically solved by reviving the code on github. There is real work
required here. And maintaining the code out-of-tree is going to be much
much harder than keeping it in mainline. Noone else will look at
out-of-tree code even if they break it by changing some API.  And you
end up having to support multiple versions of the APIs as they change.

But maybe you already offered to take over IrDA and I just missed it?


Bjørn

Hi Bjørn,

thanks for your comment.

I might be wrong but that just sounds like a lot of work and
responsibility which I cannot currently offer.

Actually all motivation I know is that it "has long been obsolete and
broken". It's probably obsolete in sense of "Infrared what?!" for most
users, yes. Also, the code style might be obsolete in terms of modern
kernel hacking but that isn't really an issue in my eyes. I have no
concrete example for what's broken. There is an unanswered request for
such examples on the Kernel.org Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=198657

That's my intention for keeping it out-of-tree. I don't want others to
*have* to look at it when they change some API and I do expect the work
caused by such changes to have a manageable amount for me.

Right, that might become an if-else (or branches / patches) hell at some
point. That's definitely a downside of out-of-tree.

Any further feedback is very welcome.

Christopher

This seems really wrong.  Note GregKH's commit message:

# It's time to get rid of IRDA.  It's long been broken, and no one seems
# to use it anymore.  So move it to staging and after a while, we can
# delete it from there.

You just disproved that "no one seems to use it", and you also volunteer to
do the work fixing it.

Maintaining an out-of-tree module is drastically more work than in-tree.  It
doesn't get testing (even if compile-only), doesn't see updates when people
change internal interfaces, and notoriously gets out of sync with current
kernels.  Quality requirements for staging drivers are really low precisely
to discourage people from working out of tree.

I think you really need to talk to GregKH and submit your fixes there.


Meow!