NI-DAQmx Base 15.0: nikal.c build failure

[bnc2]

 The computer contains a:

$ lspci | grep -i national
05:00.0 Unassigned class [ff00]: National Instruments PCI-6014

 It appears the newest software which supports the PCI-6014 is NI-DAQmx Base 15.0. According to its README.txt, that version has "operating system support" for "CentOS 7 (x86_64)". I therefore

1. installed CentOS 7 on a computer with a blank disk
2. attempted to install NI-DAQmx Base 15.0

but this failed with

Configuring NI-KAL for kernel version 3.10.0-1160.36.2.el7.x86_64...
Building module nikal...
nikal: CC [M] /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.o
nikal: /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c:2019:10: error: ‘GENL_ID_GENERATE’ undeclared here (not in a function)
nikal: .id = GENL_ID_GENERATE,
nikal: ^
nikal: /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL100_initDriver’:
nikal: /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c:2059:4: error: implicit declaration of function ‘genl_register_family_with_ops’ [-Werror=implicit-function-declaration]
nikal: if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;
nikal: ^
nikal: /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL240_do_munmap’:
nikal: /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c:3699:4: error: too few arguments to function ‘do_munmap’
nikal: return do_munmap(mm, addr, len);
nikal: ^
nikal: In file included from /var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.c:61:0:
nikal: include/linux/mm.h:2089:12: note: declared here
nikal: extern int do_munmap(struct mm_struct *, unsigned long, size_t,
nikal: ^
nikal: cc1: some warnings being treated as errors
nikal: make[2]: *** [/var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal/nikal.o] Error 1
nikal: make[1]: *** [_module_/var/lib/nikal/3.10.0-1160.36.2.el7.x86_64/nikal] Error 2
nikal: make: *** [nikal.ko] Error 2
nikal: ERROR: failed to build nikal

[bnc2]

[Apparently my reply which pointed out that the configure check for the number of arguments to do_munmap in nikal's configure, and the interesting call in nikal.c of do_munmap with a value of 1 to a pointer argument has been removed. Admittedly also removing the irrelevant reply talking about MacOS X was a Good Thing(tm)]

So, given the compile errors in the nikal.c packaged with NI-DAQmx Base 15.0, which seems to be the most recent software to support a PCI-6014 (and CentOS7), I thought I would try "NI-KAL 17.5.1". This compiled out of the box, with no warnings. Unfortunately, it doesn't load. dmesg says:

nipalk: Unknown symbol nNIKAL220_tPageList_destroy (err 0)
nipalk: Unknown symbol nNIKAL100_createSemaphore (err 0)
nipalk: Unknown symbol nNIKAL100_pageLockUserPointer (err 0)
nipalk: Unknown symbol nNIKAL100_mapKernelToUser (err 0)
nipalk: Unknown symbol nNIKAL100_registerDriver (err 0)
...

 Still looking for a way to talk to the PCI-6014 we own...

[bnc2]

I really didn't expect this response:

It's neither a Ubuntu bug, nor a upstream one.

Instead it's entirely NI's fault: they're using an GPL-only symbol (which IIRC always has been GPL-only!) in their proprietary kernel driver. (the idea of binary-only kernel drivers alone is quite insane in the first place).

The only serious fix is NI releasing their driver as GPL, or somebody reverse-engineering it and writing a free driver.

It seems there is no hope for the PCI-6014 we own

[rolfk]

The chance for a company to release their drivers under the GPL is very slim. It's the main problem why a lot of hardware support on Linux is so hampered. The Linux folks want to force the GPL on anyone, and the commercial folks hate it like the devil the holy water.

And many kernel APIs haven't always been GPL only. But somewhere along the way, some people felt it was a good way to force hardware providers to open source their drivers and after changing the policy that certain APIs could only be called by GPL software, they also started to actively enforce that through compile time hurdles that simply failed with precompiled object files. It has prompted a few companies to either GPL some (often alpha quality drivers) or release some crappy hardware documentation and many more to more or less withdraw from Linux. You gain a little and loose some, that's the name of the game.

[bnc2]

Anyone feel like supporting the *BSDs? Nevermind - the bottom line is still, we own a PCI-6014, and still haven't solved the puzzle on how to talk to it. The usual forum type answer "upgrade" certainly isn't going to work.

[rolfk]

You can use that hardware, just not under Linux. It was never sold with the promis to work under Linux in the first place since NI always had a somewhat difficult time to determine how to deal with Linux on desktops. From my own experiences with Linux this isn't entirely surprising. The Linux folks have a strong tendency to create, modify and abandone subsystems pretty whimsically and the divers ecoverse of different distributions may be interesting to serve a variety of different needs of different types of users but is a true nightmare to support, if you have to deliver software that should work on more than one distribution and on multiple versions.