The KDIR variable assignment gets overwritten by the KDIR=... in the
make invocation started from dkms. So it gets never used.
(See:
https://stackoverflow.com/questions/2826029/passing-additional-variables-from-command-line-to-make
)
Even if it would be used it would lead to compilation errors, since KDIR
has to be defined by dkms (when it "cross-compiles" for other kernels), not by
uname with our current kernel
Other compilation units (CUs) including this header file do not need
module parameter handling. It's specific to our CU. Header files are meant to
communicate/interface with outside CUs
Static global variables are compilation unit (CU) local. Making them accessible
to each other CU that includes our .h file makes no sense, they are internal
variables of our CU, therefare, move them to our CU file. .h files are for
"interfaces" to other CUs
Making a function static means "this function is compilation-unit-locale and
cannot be used (linked to) by others".
Putting a function prototype p into a header file h means every other module m
that includes h can call p.
Putting a static function prototype into a header file means "you can call this,
but you can not call this" which makes no sense. All this prototypes all only
needed compilation unit internally (and should only be used so). This commit
moves them where they belong. And subsequent commits will clean them up
because most are not necesarry in the .c file.
With warnings on DKMS builds (mention the potential for vermagic conflicts if step 1 & 2 are done on the same build), and recommend skipping straight to the DKMS option on systems where DKMS is present.
Future proposal: Create a makefile to automate the DKMS setup in one step.
