1

Scenario 1: I'm trying to install IBM GPFS driver onto RHEL6 with a vanilla kernel 3.10 (actually, kernel-lt from Elrepo). The GPL part won't compile due to:

  • Too many/too few arguments passed to function
  • struct x has no such member
  • type mismatch

Their code compiles fine on stock RHEL/Suse kernels older or newer than mine, but fails here.

Scenario 2: I'm trying to compile the opensource softiwarp driver on RHEL6 with stock kernel, but it fails with same errors as in scenario 1. However, it compiles fine on a vanilla kernel.

This all is because their feature-check headers look like this:

#if LINUX_KERNEL_VERSION >= 2061300
#define FOO <newer variant>
#else
#define FOO <older variant>
#endif

But RHEL and Suse have many backports and bugfixes, so their 3.10.101 is not the same as vanilla 3.10.101.

How to write code that will check features, not version number? In a user-space program I would use autoconf macros AC_CHECK_MEMBER/AC_CHECK_FUNC

basin
  • 3,949
  • 2
  • 27
  • 63

1 Answers1

0

How to write code that will check features, not version number? In a user-space program I would use autoconf macros AC_CHECK_MEMBER/AC_CHECK_FUNC

The standard preprocessor's capabilities are much less than some people seem to think. It has no ability to do what you want directly. Autoconf provides no magic in this regard, either; it simply performs tests at configuration time, often simply by checking whether the compiler accepts a given piece of code, and it communicates the results to the compiler largely by causing preprocessor macros to be defined. (And you are responsible for using those macros as needed in conditional tests much like the one in your example.)

Since we're talking about Autoconf, however, as long as it runs against the kernel headers that correspond to the kernel you're building for, at least some Autoconf macros should work for you, and you should be able to write custom Autoconf tests for others. Indeed, any issue that that the compiler can detect at build time, Autoconf should also be able to test for.

Of course, there is also the option of giving the module builder the ability to indicate needed configuration details explicitly where a thorny issue such as this arises. For example, adjust the feature selection macros to pay attention also to a symbol reserved for the builder to use to modulate the results.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • What?! Autotools are heavily rely on underneath libc. How can you use them with kernel without hacking themselves? – 0andriy Jun 23 '16 at 09:37
  • @AndyShevchenko, you might as well say "`gcc` and `make` rely on libc, so how can you use them to build kernels?" The fact is that the Autoconf checks relevant to your problem rely on testing via the compiler, so, as I said, you simply need to ensure that the kernel headers it consults are the right ones. Autoconf knows how to perform plenty of checks that don't make sense for a kernel build (e.g. library checks), but that does not mean you cannot use the checks that do make sense. – John Bollinger Jun 23 '16 at 14:30
  • Although I don't like your presumption of my ignorance in the 1st paragraph @JohnBollinger, the rest of your answer makes sense. I'll accept it – basin Jul 17 '16 at 16:51