> While the "top side" API is > very stable so that applications hardly *ever* experience API changes > that require on-going tedious maintenance, the same cannot be said of code > that runs in the kernel. Quite the contrary. Linus and friends > *routinely and regularly* change critical APIs within the kernel, > sometimes even across minor version revs of the same codebase.
Come on, it's not _that_ bad ... Kernel API are stable inside the maintenance release, so they can only change like every 2 month at most. And when they change, finding the relevant commit is pretty easy with git and it will show exactly what need to be changed in your driver (because that commit fixed every other driver in-tree for the same change). And searching LKML will also give all the gory details. It's like half a day or one day of work at the most. So 1 day of code maintenance every 2 month to keep your codebase current is not what I'd call a nightmare. And if you want to avoid even that, just get your module merged upstream, it will be adapted for you free of charge when APIs change. And wrt to maintaining the same code building for several kernel, that's just the wrong approach. Just maintain different version in different branches. When the code is well written, the driver specific part will be decoupled enough from the kernel api part that there will hardly be any conflicts. And when your driver "core function" doesn't change (and for the NI driver, it seems it hasn't changed it's functionality for a while AFAICT, just added new kernel support, but I could be wrong on that), then it's even easier to just release a new code for each new kernel. For only a few revisions appart, you might be ok with #ifdef, but if you're trying to go back to ancient times, like the NI module which seems to support 2.6.0 (that's 11 years ago !!!!), yeah there is going to be some serious changes ... Cheers, Sylvain PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver for a FPGA board, so I did experience that. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
