During the project development process, many applications require common I/O operations, data structures, and algorithms. If each application needs to rewrite these functionalities, it will inevitably reduce development efficiency and increase the possibility of code instability. Therefore, many large projects develop basic libraries or services for other applications to use. These components are referred to as core components in OpenWrt, with the most fundamental being the libubox that we will introduce today.<span><span>libubox</span></span>The software package is a basic library added to new versions after the <span><span>OpenWrt 12.09</span></span> version, and many applications in OpenWrt 15.07 are based on <span><span>libubox</span></span>, such as <span><span>ubus</span></span>, <span><span>netifd</span></span>, and <span><span>freecwmp</span></span>. This brings several benefits: we do not need to focus on the underlying basic functionalities and can develop further functionalities based on the stable API provided by <span><span>libubox</span></span>.libubox mainly provides the following three functionalities:
- (1) Provides various basic common function interfaces, including linked lists, balanced binary trees, binary block processing, key-value linked lists, MD5, etc.
- (2) Provides various socket interface encapsulations
- (3) Provides a set of event-driven mechanisms and task queue management functionalities
This article mainly introduces the directory structure of the project, and subsequent sections will detail the specific functionalities and usage of each module.Source PathThe libubox software package is located in package/libs/libubox, but it only contains a top-level Makefile that describes the software package. The actual source code is stored in a compressed package:
ruok@ruok-vm:~/Desktop/openwrt$ tree -L 2 package/libs/libubox/package/libs/libubox/└── Makefile
0 directories, 1 file
ruok@ruok-vm:~/Desktop/openwrt$ ls dl/libubox-2021-05-16-b14c4688.tar.xz dl/libubox-2021-05-16-b14c4688.tar.xz
Code StructureDuring the compilation process, the source code compressed package will be downloaded to the dl directory and then extracted to the corresponding build_dir location for subsequent compilation operations. Of course, we can also extract it ourselves for analysis:
ruok@ruok-vm:~/Desktop/openwrt/dl$ tar -Jxf libubox-2021-05-16-b14c4688.tar.xz
ruok@ruok-vm:~/Desktop/openwrt/dl$ cd libubox-2021-05-16-b14c4688/
ruok@ruok-vm:~/Desktop/openwrt/dl/libubox-2021-05-16-b14c4688$ tree -L 2.
├── assert.h
├── avl.c
├── avl-cmp.c
├── avl-cmp.h
├── avl.h
├── base64.c
├── blob.c
├── blob.h
├── blobmsg.c
├── blobmsg.h
├── blobmsg_json.c
├── blobmsg_json.h
├── CMakeLists.txt
├── examples│ ├── CMakeLists.txt│ ├── json_script-example.c│ ├── json_script-example.json│ ├── json_script-tests.sh│ ├── shunit2│ ├── uloop-example.lua│ ├── uloop_pid_test.sh│ └── ustream-example.c
├── jshn.c
├── json_script.c
├── json_script.h
├── kvlist.c
├── kvlist.h
├── list.h
├── lua│ ├── CMakeLists.txt│ └── uloop.c
├── md5.c
├── md5.h
├── runqueue.c
├── runqueue.h
├── safe_list.c
├── safe_list.h
├── sh│ └── jshn.sh
├── tests│ ├── CMakeLists.txt│ ├── cram│ ├── fuzz│ ├── shunit2│ ├── test-avl.c│ ├── test-b64.c│ ├── test-b64_decode.c│ ├── test-b64_encode.c│ ├── test-blob-buflen.c│ ├── test-blobmsg.c│ ├── test-blobmsg_check_array.c│ ├── test-blobmsg-parse.c│ ├── test-blobmsg-procd-instance.c│ ├── test-blobmsg-types.c│ ├── test-blob-parse.c│ ├── test-json-script.c│ ├── test-list.c│ └── test-runqueue.c
├── ulog.c
├── ulog.h
├── uloop.c
├── uloop-epoll.c
├── uloop.h
├── uloop-kqueue.c
├── usock.c
├── usock.h
├── ustream.c
├── ustream-fd.c
├── ustream.h
├── utils.c
├── utils.h
├── vlist.c
└── vlist.h
7 directories, 66 files
This project is controlled by CMake for compilation, and the source code functionalities are not categorized but placed in the same directory level, which is more intuitive as shown in the following diagram:
Therefore, a simple classification is made here, first with clear functional divisions:
- CMakeLists.txt: This is the CMake configuration file used to generate Makefiles for different platforms.
- Extension Programs: Mainly the lua and sh directories, used for bindings in two programming languages.
- Test Programs: The tests folder contains many unit test programs, and examples are sample program codes, which are the best materials for learning how to use the libubox library.
The remaining source code programs are library functions provided externally, where each .c file is basically an independent module, which will be introduced in detail in subsequent articles.About CompilationDo not worry, as libubox is already one of the most basic core components in OpenWrt. Other components like procd, ubusd, netifd, etc., all require it, so this library will definitely be compiled and will be compiled before other applications.If you are still concerned, you can find the option shown in the following image in the Libraries category to confirm that it has been selected:
During the compilation process, the relevant header files will be installed in the <span>/usr/include/libubox</span> directory, for example:
ruok@ruok-vm:~/Desktop/openwrt/build_dir/target-aarch64_cortex-a53_musl/libubox-2021-05-16-b14c4688/ipkg-install$ ls usr/include/libubox/assert.h avl.h blobmsg.h json_script.h list.h runqueue.h ulog.h usock.h utils.havl-cmp.h blob.h blobmsg_json.h kvlist.h md5.h safe_list.h uloop.h ustream.h vlist.h
If you need to use the relevant header files, you should use commands like the following:
#include <libubox/utils.h>
For example, below is a snippet of code from the <span>ubus/ubusd.h</span> file:
#ifndef __UBUSD_H
#define __UBUSD_H
#include <libubox/list.h>
#include <libubox/uloop.h>
#include <libubox/blobmsg.h>
#include "ubus_common.h"
#include "ubusd_id.h"
#include "ubusd_obj.h"
#include "ubusmsg.h"
#include "ubusd_acl.h"
#define UBUS_OBJ_HASH_BITS 4
#define UBUS_CLIENT_MAX_TXQ_LEN UBUS_MAX_MSGLEN
So, there is no need to worry too much about how to use this library; I will provide a code framework in the next article to facilitate writing test programs later.