背景
对于静态库的封装，大多数情况在应用层应用的封装的比较多，用起来比较熟悉。不过，在嵌入式开发中，有些时候，需要将一些私有修改隐藏起来，特别是，内核中的一些修改。
此时需要在内核态制作静态库，然后链接到整个内核文件中。
对于一般（没有复杂的内核依赖关系）的内核静态库的封装，直接安装应用层封装即可。
对于内核中一些高级驱动的私有修改，在进行封装时，就需要格外注意了，包括正确编译，头文件交叉引用，如果正确被链接到内核中，而不是被编译器忽略掉了。
封装问题
我们以 usb_f_uvc.ko 这个uvc function driver为例，来分析，内核静态库的封装（假设，以下文件有修改或者定制）。最终，将usb_f_uvc.ko 打包成一个 静态库，链接到内核里面。
# kernel/drivers/usb/gadget/function/Makefile usb_f_uvc-y := f_uvc.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_configfs.o obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o
编译
我们将需要的文件，复杂到一个目录下，修改Makefile
# Makefile # 可换成自己的工具链 CROSS_COMPILE ?= arm-linux-gnu- CC := $(CROSS_COMPILE)gcc LD := $(CROSS_COMPILE)ld AR := $(CROSS_COMPILE)ar CP := cp RM := rm # 修改正确的kernel 路径 KERNEL_PATH := xxxx/kerenl # 获取gcc 版本 CC_PATH := ${shell which $(CC)} CROSS_COMPILE_PATH := ${shell dirname $(CC_PATH)} CFLAGS := -nostdinc -isystem $(CROSS_COMPILE_PATH)/../lib/gcc/arm-linux-gnu/7.2.0/include # 头文件顺序很重要，换成自己平台的 INCLUDE = -I$(KERNEL_PATH)/arch/arm/include \ -I$(KERNEL_PATH)/arch/arm/include/generated/uapi \ -I$(KERNEL_PATH)/arch/arm/include/generated \ -I$(KERNEL_PATH)/include \ -I$(KERNEL_PATH)/arch/arm/include/uapi \ -I$(KERNEL_PATH)/include/uapi \ -I$(KERNEL_PATH)/include/generated/uapi/ \ -include $(KERNEL_PATH)/include/linux/kconfig.h INCLUDE += -I$(KERNEL_PATH)/arch/arm/xxxx/core/include \ -I$(KERNEL_PATH)/arch/arm/xxxx/soc-xxx/include \ -I$(KERNEL_PATH)/arch/arm/include/asm/mach-generic #CFLAGS += -fno-delete-null-pointer-checks -Wno-maybe-uninitialized -Wno-frame-address -Wno-format-truncation \ #-Wno-format-overflow -Wno-int-in-bool-context -Os --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO \ #-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable \ #-fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement \ #-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int \ #-Werror=strict-prototypes -Werror=date-time CFLAGS += -DEXPORT_SYMTAB # 这个一定要加 CFLAGS += -D__KERNEL__ CFLAGS += $(INCLUDE) OBJS := uvc_queue.o uvc_v4l2.o uvc_video.o f_uvc.o uvc_configfs.o ARFLAG := -rcs LIB_TARGET := libxxx.a TARGET := libxxx.hex all: $(TARGET) %.o:%.c $(CC) $(CFLAGS) -o $@ -c $^ $(TARGET): $(LIB_TARGET) $(CP) $(LIB_TARGET) $(TARGET) $(CP) -vf $(TARGET) $(KERNEL_PATH)/drivers/usb/gadget/function/ $(LIB_TARGET): $(OBJS) $(AR) $(ARFLAG) $@ $^ clean: find . -name "*.o" | xargs rm -r $(RM) -vf $(LIB_TARGET) $(TARGET) install: $(CP) -vf $(TARGET) $(KERNEL_PATH)/drivers/usb/gadget/function/
Makefile 参数和头文件如何来？
事实上，整个内核打包的过程，笔者认为，编译是最难的一步，特别是第一次接触的时候。
对于驱动中的各符号和宏的定义，以及头文件包含是层层套娃，根据错误信息定位，简直要崩溃。
在这里，笔者建议，先参考【内核编译参数选项】，然后在逐一删减无关选项，这样会方便很多。
具体操作如下：
- 正常编译内核：
- touch 修改 f_uvc.c：
- 重新编译内核：make uImage V=1 > build.txt
- vim build.txt 搜索f_uvc 即可看到编译信息
使用 make V=1 参数将编译的详细信息输出，包括头文件包含顺序，gcc 编译参数选项等，然后将其添加到我们的Makefie上。最后在对我们的Makfile 做删减。
添加到内核
#kernel/drivers/usb/gadget/function/Makefile usb_f_uvc-y := libxxx.a #obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o obj-y += usb_f_uvc.o # 防止Make distclean 把所有 .a都清掉了 $(obj)/libxxx.a: $(obj)/libxxx.hex cp $(obj)/libxxx.hex $(obj)/libxxx.a
编译内核
重新编译内核，将.a 链接到内核。然后烧到板子运行。
运行
实际运行，发现根本没有链到板子去。
原因分析
查看 EXPORT_SYMBOL
打开 Module.symvers 发现，uvc 相关的接口并没有导出来，猜测有可能没有成功链到内核。
vim Module.symvers
objdump 反汇编
使用objdump 将所有的符号表都输出来，然后在搜索查看，进一步确认链接是否正确。结果发现也找不到任何符号信息
arm-linux-gnu-objdump -Dz vmlinux > kernel.dump
此时一个大胆的想法出现了，是否是被编译器给优化掉了？因为是静态库，对于库文件来说，其本身只是一些接口，自身不能执行调用过程。如果接口没有人调用，那么所有相关的符号是否自动被忽略了？考虑一波对编译链接的理解
分析源码
//f_uvc.c DECLARE_USB_FUNCTION_INIT(uvc, uvc_alloc_inst, uvc_alloc); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Laurent Pinchart");
这里的 DECLARE_USB_FUNCTION_INIT 很重要。我们，具体展开。
#define DECLARE_USB_FUNCTION_INIT(_name, _inst_alloc, _func_alloc) \ DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc) \ static int __init _name ## mod_init(void) \ { \ return usb_function_register(&_name ## usb_func); \ } \ static void __exit _name ## mod_exit(void) \ { \ usb_function_unregister(&_name ## usb_func); \ } \ module_init(_name ## mod_init); \ module_exit(_name ## mod_exit)
这里看到 module_init 应该很熟悉了，对于我们上面封装的库来说，本质上也是一个驱动，是驱动就有对应的入口和出口。
对于内核，所有的入口都被放在 .text.init 处，加载到内核中后会按照相应顺序进行初始化。
如果我们，把整个驱动封装成一个静态库，DECLARE_USB_FUNCTION_INIT 属于库的接口，本身不会自己调用。所以内核在链接的过程中，发现没有调用关系，就自然而然会忽略掉libxxx.a的相关符号。
知道了原因，解决方法就很简单了。在内核中一定要存在有调用
DECLARE_USB_FUNCTION_INIT的地方。
- 方法1：手动调用。不推荐
- 方法2：自动调用。沿用内核驱动模型。将 DECLARE_USB_FUNCTION_INIT 从静态库中剥离出来，其他文件打包成一个库。
修改如下：
// entry.c #include <linux/kernel.h> #include <linux/module.h> #include <linux/device.h> #include <linux/errno.h> #include <linux/list.h> #include <linux/mutex.h> #include <linux/string.h> #include <linux/usb/ch9.h> #include <linux/usb/gadget.h> #include <linux/usb/video.h> #include "u_uvc.h" #include "f_uvc.h" static struct usb_function_instance *uvc_alloc_inst(void) { return uvc_alloc_inst_callback(); } static struct usb_function *uvc_alloc(struct usb_function_instance *fi) { return uvc_alloc_callback(fi); } DECLARE_USB_FUNCTION_INIT(uvc, uvc_alloc_inst, uvc_alloc); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Laurent Pinchart");
重新修改Makefile
usb_f_uvc-y := entry.o libxxx.a obj-y += usb_f_uvc.o #obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o $(obj)/libxxx.a: $(obj)/libxxx.hex cp $(obj)/libxxx.hex $(obj)/libxxx.a
这样重新，编译内核，就可以用了。以后只需要更新libxxx.a 即可。
总结
本文简单介绍内核静态库，打包遇到的一些坑。通过一个例子，介绍内核静态库的封装，以及遇到的问题。
同时也加深了对编译和链接的理解。有关应用层静态库和内核态的库在使用上是一样的，不过在制作时有些许麻烦。
- 头文件的引用包含
- 编译参数选项
- 是否成功链接
有关驱动入口的部分，不能做到库里面，避免踩雷。折腾其他，结果发现是链接时出了问题。
