how not to write driver Makefiles or configuration scripts

if [uname -r eq ...] Its very bad form to insist on very particular versions of an OS/kernel. Not only will you piss off your customer (me), you will cause a great deal of effort to unwind the ill-considered test in order to get even basic functionality. I’ve seen this on network cards, RAID cards, you name it. It increases your support load, decreases the likelihood that you can actually support whats out there … say for example, someone does a ‘yum update’ and gets an updated kernel. And suddenly their drivers don’t work, as they CANT BE COMPILED FOR THE UPDATED DRIVER THANKS TO CHECKS LIKE THIS. A while ago, I used to edit the OFED install.pl, and maintained a patch to remove some of the more egregious crap I found in there. It got old after a while, but it was the only way to make sure our stuff worked correctly regardless of what OS/kernel revision we were on. Now we’ve got to do similar things across many different driver classes. We sometimes have to do forward ports, where the old in-kernel drivers had the corrected logic for things like new sg interfaces, and the updated driver with the old interface, maintained outside of the kernel, didn’t. Unfortunately, most of these folks rarely if ever sync up the out of tree and in tree drivers. So you get a case where the out of tree driver has an older kernel interface, not supported anymore in modern kernels, but lots of bug fixes. The correct solution is, of course, to maintain the drivers in-tree. To keep em in sync. Some of these are up to half a decade out of sync. Very … very sad. But don’t make my life harder by trying to prevent me from fixing your issues. I can’t necessarily contribute our fixes back upstream, as the driver owners need to do that, and they are largely unwilling to. So we have to carry more drivers forward. And much of the carrying these things forward has to do with reworking the build bits to pull out the “lets prevent people from doing what they need to do.” /sigh