Issues with using wildcard in Makefile while build .ko from objects across directory - linux

I organized the kernel modules as different sub-component, so I can easily insert/remove existing sub-module to try or integrating stuff.
The directory layout is shown as below:
foo --+-- Makefile
|
+-- main.c
|
+-- include --+-- foo1.h
| |
| +-- ... (other headers)
|
|
+-- src ------+-- foo1.c
|
+-- ... (other sources)
Here's my Makefile,
MODULE_NAME = foo
obj-m += $(MODULE_NAME).o
# [approach 1-1]
# SRCS := main.c src/foo1.c
# [approach 1-2]
SRCS := main.c $(wildcard src/*.c)
$(MODULE_NAME)-objs += main.o $(SRCS:.c=.o)
all:
# [2] echo to check if foo-objs values changes
echo $($(MODULE_NAME)-objs)
KCFLAGS="-I$(PWD)/include" \
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I got warning shown as below when I tried to replace approach [1-1] with [1-2] in my Makefile above.
WARNING: "InitFoo1" [.../foo/foo.ko] undefined!
WARNING: "CleanuptFoo1" [.../foo/foo.ko] undefined!
From the console output, I don't see the src/foo1.c got compiled as if I am using approach [1-1] in Makefile.
# [2] echo to check if foo-objs values changes
echo main.o main.o src/foo1.o
main.o main.o src/foo1.o
KCFLAGS="-I/home/cyng93/experiment/issues/so_kbuild_wildcard/include" \
make -C /lib/modules/4.4.23-PT-ProbeOn-AuditOn+/build M=/home/cyng93/experiment/issues/so_kbuild_wildcard modules
make[1]: Entering directory '/linux'
CC [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/main.o
LD [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "InitFoo1" [/home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko] undefined!
WARNING: "CleanupFoo1" [/home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko] undefined!
CC /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.mod.o
LD [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko
make[1]: Leaving directory '/linux'
I try to echo foo-objs(check [2] in Makefile) and found out that the value are the same for both approach [1-1] & [1-2].
Does anyone on SO has came up with similar issues can help to shade some light on ?
(I prefer [1-2] because it can save my effort from updating the Makefile when new sub-component is added)
Below I also attached the source code of main.c, foo1.c & foo1.h.
You can also check the github repo for this issue for easier access to those code.
main.c
#include <linux/module.h>
#include "foo1.h"
static int myinit(void)
{
printk("Module inserted!\n");
InitFoo1();
return 0;
}
static void myexit(void)
{
CleanupFoo1();
printk("Module removed!\n");
}
module_init(myinit);
module_exit(myexit);
MODULE_LICENSE("GPL v2");
Here, foo1 is a sub-component, where simply print out some stuff during its intialization and cleanup:
./include/foo1.h
#ifndef FOO1_H
#define FOO1_H
int InitFoo1(void);
void CleanupFoo1(void);
#endif
./src/foo1.c
#include <linux/module.h>
#include "foo1.h"
int InitFoo1(void)
{
printk("Init Foo1\n");
return 0;
}
void CleanupTest(void)
{
printk("Cleanup Foo1\n");
}
update_2018/01/15
According to Tsyvarev answer below, one can correct the Makefile by modifying Makefile as below:
MODULE_NAME = foo
obj-m += $(MODULE_NAME).o
# [approach 1-1]
# SRCS := main.c src/foo1.c
# [approach 1-2 (not working)]
# SRCS := main.c $(wildcard src/*.c)
# [approach 1-2 (working)]
MISC := $($(src)/wildcard src/*.c)
SRCS := main.c $(MISC:$(src)%/=%)
$(MODULE_NAME)-objs += main.o $(SRCS:.c=.o)
all:
# [2] echo to check if foo-objs values changes
echo $($(MODULE_NAME)-objs)
KCFLAGS="-I$(PWD)/include" \
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

When build the kernel module your Makefile is processed twice:
When you type make from your module's directory.
Inside Kbuild process, because you pass M=$(PWD) option to it.
First time the Makefile is processed with current directory equal to the module's directory. So wildcard works as expected, which is confirmed by printing from all receipt.
But the second time the Makefile is processed with current directory equal to kernel's build directory (/lib/modules/4.4.23-PT-ProbeOn-AuditOn+/build in your case). In that mode
$(wildcard src/*.c)
attempts to find a file in kernel's build directory, which obviously fails.
At the time of second processing one may refer to module's build directory with $(src).
Such way one may use wildcard() for collect module's sources. But note, that Kernel build system expects path to source file (more precisely, to object file) to be relative to module's build directory. So, one need to strip $(src) component of every file obtained with wildcard().

Related

GET WARNING: modpost: missing MODULE_LICENSE() when LKM is Compiled with Multiple Src files

I have a LKM named RtmNetlinkLKM.c and compiles and run fine. The moment I update its Makefile to compile with other src files, it starts giving warning:
WARNING: modpost: missing MODULE_LICENSE()
The following MODULE_LICENSE("GPL"); is already present in kernel module file.
Previous Makefile, module compiles fine
obj-m += RtmNetlinkLKM.o
all:
make -C /lib/modules/`uname -r`/build M=$(PWD) modules
clean:
make -C /lib/modules/`uname -r`/build M=$(PWD) clean
updated Makefile, module now compiles with a warning
obj-m += RtmNetlinkLKM.o
RtmNetlinkLKM-objs += rt_kern.o gluethread/glthread.o << Added two more sources
all:
make -C /lib/modules/`uname -r`/build M=$(PWD) modules
clean:
make -C /lib/modules/`uname -r`/build M=$(PWD) clean
rm -f rt_kern.o
rm -f gluethread/glthread.o
When compiled using second Makefile, it gives stated warning. When I add MODULE_LICENSE("GPL") in gluethread/glthread.c , warning goes away. I don't understand, why do I need to add "GPL" license in glthread.c when it is not a module but contain functions to be used by module (It is a linked list mini-library). Why doesn't it complain with other src file rt_kern.c in a similar way. I had never made any changes in original module file RtmNetlink.c throughout this process.
Thanks to #Gautham Kantharaju in link provided by #Tsyvarev for solving my problem. While compiling multiple source files into a single module, the main reason for the warning seems to be, ".. it is not possible to have the module name and the source name to be the same."
If anyone else has the same question, I think following Makefile should solve the issue.
# give your module a different Name
obj-m += newModuleName.o
newModuleName-objs += RtmNetlinkLKM.o rt_kern.o gluethread/glthread.o
all:
make -C /lib/modules/`uname -r`/build M=$(PWD) modules
clean:
make -C /lib/modules/`uname -r`/build M=$(PWD) clean

Linux Kernel Module - Sharing variables between source files

I'm trying to link a kernel module to a non-LKM source file. The problem is, I'm running into some issues. The names of the two files are chardev.c (the LKM) and foo.c.
My Makefile:
obj-m += chardev.o
obj-y += foo.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
$(CC) test.c -o test
clean:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean
rm test
Inside of chardev.c I've the following line of code: extern int foo;, and inside foo I've the following line of code: int foo = 123;. (Both lines are at file-scope.)
When running make I'm getting the following output:
make -C /lib/modules/4.4.0-31-generic/build/ M=/home/kylemart/Desktop/Device-Driver modules
make[1]: Entering directory `/usr/src/linux-headers-4.4.0-31-generic'
CC [M] /home/kylemart/Desktop/Device-Driver/chardev.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "foo" [/home/kylemart/Desktop/Device-Driver/chardev.ko] undefined!
CC /home/kylemart/Desktop/Device-Driver/chardev.mod.o
LD [M] /home/kylemart/Desktop/Device-Driver/chardev.ko
make[1]: Leaving directory `/usr/src/linux-headers-4.4.0-31-generic'
cc test.c -o test
Seems things aren't linking properly. What am I doing wrong?
EDIT:
This seems to work, but there's a problem:
obj-m += chardev.o
chardev-objs += foo.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
$(CC) test.c -o test
clean:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean
rm test
Although it compiles without warnings, after installing the compiled module (i.e. sudo insmod chardev.ko) there isn't a new device present in /dev. Previously, without trying to link source files, installing kernel modules as previously stated created a device file. That said, the device is present when running lsmod.
Your all target builds only the module, but not the kernel so that the foo symbol does not exist there.
When compiling a source (here: foo.c) into the kernel, you have to integrate the makefile into the kernel source. E.g. you have to add
obj-y += my-driver/
to the makefile in the previous directory and build the whole kernel. You should probably remove your all: and clean: targets from the makefile to avoid conflicts with kernel builtin rules.
foo.c must contain
EXPORT_SYMBOL(foo);
or
EXPORT_SYMBOL_GPL(foo);
The second makefile...
will generate only the chardev.ko module which is built from only foo.c; chardev.c will not be used for it. When you really want this, you have to change file names; e.g.
obj-m += chardev.o
chardev-objs = chardev-core.o foo.o

Set output path when compiling a kernel module?

Is it possible to provide an output folder when building a kernel module?
These questions are very similar to mine but the answers are non conclusive Link1, Link2 (I have tested these proposals without success).
I have the following project structure and would like to put all outputs from the compiling of the kernel module into the build folder.
Makefile
src/
-main.c
build/
This is my current Makefile:
# name of the module to be built
MODULE_NAME ?= test_module
BASE := .
# define all module sources
SRCS := \
src/main.c
# extract required object files
OBJ_SRCS := $(SRCS:.c=.o)
# define path to directories containing header files
INCLUDE_DIRS = \
-I$(src)/src
# Products from the 'make all' command should be placed in this folder
BUILD_DIR := $(BASE)/build
# ccflags to pass at compile time
ccflags-y := \
$(INCLUDE_DIRS)
# setup kbuild stuff
obj-m += $(MODULE_NAME).o
$(MODULE_NAME)-y := $(OBJ_SRCS)
$(MAKE) = make
KERNEL_DIR=/lib/modules/$(shell uname -r)/build
all:
$(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules
clean:
$(MAKE) -C $(KERNEL_DIR) M=$(PWD) clean
I have tried to add O=$(BUILD_DIR) as (as stated in the link above without success).
$(MAKE) -C $(KERNEL_DIR) O=$(BUILD_DIR) M=$(PWD) modules
Can anyone confirm if it is possible to redirect to output(the files generated during the compilation) when compiling the kernel module or not? (A suggestion would be much appreciated)
Is the only solution to put the Makefile in the build folder and update the all paths in the Makefile?
Thanks!

How to rename a kernel module name without renaming the .ko passed to insmod?

I need to rename a kernel module (the name that get displayed with lsmod) of an already existing driver without changing the name of the source file.
e.g.
# insmod xxx.ko
<<module loads successfully>>
# lsmod
Module Size Used by Tainted: P
xxx 191527 0
#
I want to rename xxx to yyy.
Now I know that changing the name of the driver source file (when it involves a single file) changes the name of the module.
But I don't want to change the name of a source file.
Rename your obj-m in Makefile and set dependency of obj-m to original module.
For example, I have file hello.c that contain all of my source code. But I want module to be mynewname.
Here is whole Makefile that does this:
obj-m := mynewname.o
mynewname-objs := hello.o
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
clean:
$(MAKE) -C $(KERNELDIR) M=$(PWD) clean
I set obj-m to mynewname.o and make mynewname.o dependant on hello.o. After invoking make you'll get mynewname.ko.

Cannot use wildcard in kernel module makefile

I am pretty familiar with Makefiles and kernel modules, but recently I got a problem in my Makefile that doesn't make any sense -- on using wildcards.
To demonstrate this, I am compiling a hello world kernel module from scratch.
The directory structure is like this:
hello_mod/
|
--- hello.c
|
--- Makefile
Here is the actual makefile :
CFILES := $(wildcard hello.c*)
#CFILES := hello.c
OBJS := $(CFILES:.c=.o)
KSRC := /lib/modules/$(shell uname -r)/build
obj-m += hello_world.o
hello_world-y := $(OBJS)
all:
#echo $(CFILES)
$(MAKE) -C $(KSRC) M=$$PWD modules
clean:
$(MAKE) -C $(KSRC) M=$$PWD clean
.PHONY: clean
The problem is that even though the commented $(CFILES) and the uncommented $(CFILES) are exactly the same, the build fails on using the first $(CFILES) with the following error:
*** No rule to make target `/home/test/hello_mod/hello_world.c', needed by
/home/test/hello_mod/hello_world.o'. Stop.
If the commented $(CFILES) is used, it works perfectly.
If someone wants to test this out, I'm including the source for the hello world source which is hello.c :
#include <linux/kernel.h>
#include <linux/module.h>
static int mod_init()
{
printk("Hello\n");
return 0;
}
static void mod_exit()
{
printk("Bye world\n");
}
module_init(mod_init);
module_exit(mod_exit);
Does anyone know why it is behaving as such? And I need to use wildcards in the makefile. Any help will be appreciated.
There are two makes happening here. The first really only relies on the KSRC variable and the recursive make call. The second make only needs the CFILES, OBJS, obj-m, and hello_world-y variables, and doesn't make use of the all: target. So your debug is showing that CFILES is set correctly for the first Make, where it's not being used, and is not showing it in the second make, where it is.
You're wildcard expanding from a different directory, and not picking up the right files. Try this for CFILES:
CFILES := $(notdir $(wildcard $M/hello.c*))
SRCDIRS := subdir1 subdir2
CFILES := $(strip $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c)))
should probably be (see foreach example in documentation)
SRCDIRS := subdir1 subdir2
CFILES := $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c))
(no need to $(strip), .... or perhaps
CFILES := $(wildcard {subdir1,subdir2}/*.c)
Use remake, probably as remake -x, to debug such issues.

Resources