Adding a Userspace C Program as a Buildroot Package
Packaging a userspace test application that depends on an existing kernel module package
In the earlier post I have explained how to add a kernel module as a new buildroot package. You can check that post here.
In this module I will explain the steps to add a program which is not a kernel module but a user space C program for testing the earlier kernel module.
Step 1 – Create the Package Directory
Following the same way as earlier start with the below step: Create a new folder under buildroot/package folder.
cd buildroot
mkdir package/test
Step 2 – Create the Package Files
Now we need to create two files inside the newly created “test” folder: Config.in and test.mk.
touch package/test/Config.in
touch package/test/test.mk
Step 3 – Populate Config.in
Now let’s populate these files with what will eventually add xyz as a new package.
config BR2_PACKAGE_TEST
bool "test"
depends on BR2_PACKAGE_XYZ
help
This is test library package for XYZ driver.
As you can see a new line has been added in the above Config.in file which starts with depends on.
depends on BR2_PACKAGE_XYZ – this is how we specify the dependency between packages. If a package is dependent on another then it will add a config option with depend on. In this case the test application is only relevant if there is the driver package available as it only tests the specific driver XYZ. Hence we have made it a dependency package of XYZ by adding this line in the Config.in. Also, as we have made this package a dependency package of package XYZ, we have to make a little modification as below:
config BR2_PACKAGE_XYZ
bool "xyz"
select BR2_PACKAGE_TEST
help
This is sample package.
This selects the test application too.
select BR2_PACKAGE_TEST line in the XYZ Config.in means that whenever the XYZ driver package is enabled, Buildroot will automatically enable the test package alongside it. The depends on BR2_PACKAGE_XYZ in the test Config.in ensures the test package cannot be selected without the driver being present.
Step 4 – Populate test.mk
TEST_VERSION = 1.0
TEST_SITE = ../path/to/your/source/code/test
TEST_SITE_METHOD = local
TEST_INSTALL_TARGET = YES
define TEST_BUILD_CMDS
$(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
endef
define TEST_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(@D)/test $(TARGET_DIR)/bin
$(INSTALL) -D -m 0755 $(@D)/run_test.sh $(TARGET_DIR)/bin
$(TARGET_DIR)/root
endef
$(eval $(generic-package))
test.mk the source path has been set as ../path/to/your/source/code/test. This is a relative path from the buildroot directory. You can specify any absolute path in your local machine as well. But important thing to remember is any relative path has to be with respect to the buildroot directory.
Step 5 – Register the Package in Buildroot
Now we have to tell the package system that we want to be added. Hence we do the below modification in the package config file: buildroot/package/Config.in
menu "Menu-name whatever you like"
source "package/test/Config.in"
endmenu
The Test Application Makefile
SRC=$(wildcard code/*.c)
CFLAGS = -Wall -g
INC=-I./include
all:
$(CC) $(INC) $(CFLAGS) $(SRC) -o test
clean:
Source Code Structure
The structure of the test source code is as below:
. ├── code │ └── test.c ├── include │ └── test.h ├── makefile ├── scripts │ └── run_test.sh └── test
Installation Commands
Now the installation as below:
$(INSTALL) -D -m 0755 $(@D)/test $(TARGET_DIR)/bin – this copies the test binary test to the $(TARGET_DIR)/bin directory and similarly:
$(INSTALL) -D -m 0755 $(@D)/run_test.sh $(TARGET_DIR)/bin
| Install command | What it installs |
|---|---|
| $(INSTALL) -D -m 0755 $(@D)/test $(TARGET_DIR)/bin | Copies the compiled test binary into the target root filesystem under /bin with executable permissions |
| $(INSTALL) -D -m 0755 $(@D)/run_test.sh $(TARGET_DIR)/bin | Copies the run_test.sh helper script into the target root filesystem under /bin with executable permissions |
Leave a Reply