PARAGON CONFIDENTIAL!
9Porting And Using Binary Kernel Module
© 2011 Pa ra g on Softw a re Group
PARAGON Technologie GmbH, Systemprogrammierung
Heinrich-von-Stephan-Str. 5c • 79100 Freiburg, Germany
Tel. +49 (0) 761 59018201 • Fax +49 (0) 761 59018130
www.paragon-software.com • sales@paragon-software.com
of d_obtain_alias function required to implement NFS support in file system driver on ARM
with some Linux kernels.
This means that NFS functionality will not be available for partitions mounted using Paragon file
system driver on specified architecture with these Kernel versions. Additionally, as Linux Kernel
is constantly evaluating, GPL flag may be added to or removed from other declarations as well.
3.3 Building driver using combined package
When Linux Kernel used in our customer's product is not yet stable, or in case there is hight
probability of Kernel configuration changes during product development, our solution can be
delivered in the form of 'combined' package, including our proprietary closed-source UFSD library
(compiled into object code) and an open-source wrapper (including configuration script), as well
as wrapper source code for file system utilities. The intent of 'combined package' release is to
accommodate our driver's interface to Kernel configuration changes and reduce turnaround time
in case urgent Kernel configuration change is introduced for the platform.
This is done after initial porting for current version of Kernel used in our customer's product. This
stage is mandatory — see Initial porting subsection for more information on the stage.
Sometimes 'combined package' can be used to build our driver for other Kernels using different
toolchain, but the ability of the package to build correctly for different kernels (and even for the
same kernel with different toolchain) cannot be guaranteed.
After Kernel configuration is changed for our customer's platform, the combined package can
then be recompiled by our customer's software engineers to make sure that binary Kernel
module is compiled against correctly configured Kernel that is used in product's firmware.
If an issue is found with binary module built for the new Kernel config our QA and support team
will need new Kernel configuration file as well as new binary image built using the new Kernel
configuration to be able to assist our customer's engineers.
Building the combined package
Build process is fairly straightforward for any engineer who ever performed cross-compilation of
Kernel modules:
# ./configure --host="<compiler_name>" --with-ks-
dir="<path_to_a_folder_containing_Kernel_source_code>" --with-kb-
dir="<path_to_a_folder_the_Kernel_was_compiled_in>"
CFLAGS="<compilation_flags>"
# make driver
Values passed to with-ks-dir and with-kb-dir parameters may be the same.
Please note that compiler settings to build the module must be the same that are used to build
Kernel. Thus, $PATH must be defined correctly and gcc command must call correct compiler for
the target architecture. Alternatively, when calling configure, --host command line
parameter must correctly specify compiler name for the architecture, like --host
x86_64_linux_gnu for x86_64 architecture, etc., and for make driver command, one must
correctly specify ARCH=... and CROSS_COMPILE=... command line parameters (e.g.
ARCH=x86_64 CROSS-COMPILE=x86_64_linux_gnu- for x86-64 target architecture compiled
8