linuxexportsymbol

❶ 怎么查看linux的内核符号表

在内核中通过/proc/kallsyms获得符号的地址

Linux内核符号表/proc/kallsyms的形成过程
./scripts/kallsyms.c负责生成System.map
./kernel/kallsyms.c负责生成/proc/kallsyms
./scripts/kallsyms.c解析vmlinux(.tmp_vmlinux)生成kallsyms.S(.tmp_kallsyms.S)，然后内核编译过程中将kallsyms.S(内核符号表)编入内核镜像uImage
内核启动后./kernel/kallsyms.c解析uImage形成/proc/kallsyms
/proc/kallsyms包含了内核中的函数符号(包括没有EXPORT_SYMBOL)、全局变量(用EXPORT_SYMBOL导出的全局变量)
如何将内核中的函数、全局变量、静态变量都导出到/proc/kallsyms

查看内核 使用 uname -a

❷ 在Linux中产生一个系统调用以及怎样通过往Linux内核中增加一个新函数从而在该内核

若要在kernel里面新增加一个自己的syscall，大致需要这么几个步骤：

a，新增自己syscall的代码，并修改相应makefile；

b，修改相应头文件，分配自己的系统调用号；

c，系统调用通过中断加查表的方式实现，所以需要在系统调用表里面增加相关的项目，这需要修改相关的汇编源文件；

d，重新编译内核，并写测试程序测试新增的syscall；

注意几点：

1，上述步骤所要修改的文件/位置等对不同处理器架构来说，不尽相同；

2，对于应用层的测试代码来说，在2.6.20版本之前，可以使用相应的_syscallN宏；

但是2.6.20版本后，这些宏已经被从kernel中去掉了，你需要使用应用层的syscall函数

来测试。

你可以在自己的syscall实现文件中加上EXPORT_SYMBOL/EXPORT_SYMBOL_GPL

等宏来导出你的全局变量或者函数，导出后，另外的模块或者其他内核代码就可以使用

这些变量和函数。

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

杭州巨立安（JulianTec）是杭州市场上

唯一由资深研发工程师所创办的机构。所以：

就专业程度和实在程度而言，杭州巨立安(JulianTec)

是您在arm架构下学习嵌入式Linux研发的上佳指导！

❸ 求一段Linux操作系统源代码分析

Linux内核的配置系统由三个部分组成，分别是：
Makefile：分布在 Linux 内核源代码中的 Makefile，定义 Linux 内核的编译规则；
配置文件（config.in）：给用户提供配置选择的功能；
配置工具：包括配置命令解释器（对配置脚本中使用的配置命令进行解释）和配置用户界面（提供基于字符界面、基于 Ncurses 图形界面以及基于 Xwindows 图形界面的用户配置界面，各自对应于 Make config、Make menuconfig 和 make xconfig）。
这些配置工具都是使用脚本语言，如 Tcl/TK、Perl 编写的（也包含一些用 C 编写的代码）。本文并不是对配置系统本身进行分析，而是介绍如何使用配置系统。所以，除非是配置系统的维护者，一般的内核开发者无须了解它们的原理，只需要知道如何编写 Makefile 和配置文件就可以。所以，在本文中，我们只对 Makefile 和配置文件进行讨论。另外，凡是涉及到与具体 CPU 体系结构相关的内容，我们都以 ARM 为例，这样不仅可以将讨论的问题明确化，而且对内容本身不产生影响。
2． Makefile
2.1 Makefile 概述
Makefile 的作用是根据配置的情况，构造出需要编译的源文件列表，然后分别编译，并把目标代码链接到一起，最终形成 Linux 内核二进制文件。
由于 Linux 内核源代码是按照树形结构组织的，所以 Makefile 也被分布在目录树中。Linux 内核中的 Makefile 以及与 Makefile 直接相关的文件有：

Makefile：顶层 Makefile，是整个内核配置、编译的总体控制文件。
.config：内核配置文件，包含由用户选择的配置选项，用来存放内核配置后的结果（如 make config）。
arch/*/Makefile：位于各种 CPU 体系目录下的 Makefile，如 arch/arm/Makefile，是针对特定平台的 Makefile。
各个子目录下的 Makefile：比如 drivers/Makefile，负责所在子目录下源代码的管理。
Rules.make：规则文件，被所有的 Makefile 使用。
用户通过 make config 配置后，产生了 .config。顶层 Makefile 读入 .config 中的配置选择。顶层 Makefile 有两个主要的任务：产生 vmlinux 文件和内核模块（mole）。为了达到此目的，顶层 Makefile 递归的进入到内核的各个子目录中，分别调用位于这些子目录中的 Makefile。至于到底进入哪些子目录，取决于内核的配置。在顶层 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 体系结构下的 Makefile，这个 Makefile 中包含了平台相关的信息。
位于各个子目录下的 Makefile 同样也根据 .config 给出的配置信息，构造出当前配置下需要的源文件列表，并在文件的最后有 include $(TOPDIR)/Rules.make。
Rules.make 文件起着非常重要的作用，它定义了所有 Makefile 共用的编译规则。比如，如果需要将本目录下所有的 c 程序编译成汇编代码，需要在 Makefile 中有以下的编译规则：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@

有很多子目录下都有同样的要求，就需要在各自的 Makefile 中包含此编译规则，这会比较麻烦。而 Linux 内核中则把此类的编译规则统一放置到 Rules.make 中，并在各自的 Makefile 中包含进了 Rules.make（include Rules.make），这样就避免了在多个 Makefile 中重复同样的规则。对于上面的例子，在 Rules.make 中对应的规则为：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@

2.2 Makefile 中的变量
顶层 Makefile 定义并向环境中输出了许多变量，为各个子目录下的 Makefile 传递一些信息。有些变量，比如 SUBDIRS，不仅在顶层 Makefile 中定义并且赋初值，而且在 arch/*/Makefile 还作了扩充。
常用的变量有以下几类：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定义了当前内核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它们共同构成内核的发行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 体系结构：ARCH
在顶层 Makefile 的开头，用 ARCH 定义目标 CPU 的体系结构，比如 ARCH:=arm 等。许多子目录的 Makefile 中，要根据 ARCH 的定义选择编译源文件的列表。
3） 路径信息：TOPDIR, SUBDIRS
TOPDIR 定义了 Linux 内核源代码所在的根目录。例如，各个子目录下的 Makefile 通过 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定义了一个目录列表，在编译内核或模块时，顶层 Makefile 就是根据 SUBDIRS 来决定进入哪些子目录。SUBDIRS 的值取决于内核的配置，在顶层 Makefile 中 SUBDIRS 赋值为 kernel drivers mm fs net ipc lib；根据内核的配置情况，在 arch/*/Makefile 中扩充了 SUBDIRS 的值，参见4）中的例子。
4） 内核组成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 内核文件 vmlinux 是由以下规则产生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o
--start-group
$(CORE_FILES)
$(DRIVERS)
$(NETWORKS)
$(LIBS)
--end-group
-o vmlinux
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 组成的。这些变量（如 HEAD）都是用来定义连接生成 vmlinux 的目标文件和库文件列表。其中，HEAD在arch/*/Makefile 中定义，用来确定被最先链接进 vmlinux 的文件列表。比如，对于 ARM 系列的 CPU，HEAD 定义为：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被链接到 vmlinux 中。PROCESSOR 为 armv 或 armo，取决于目标 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在顶层 Makefile 中定义，并且由 arch/*/Makefile 根据需要进行扩充。 CORE_FILES 对应着内核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，这些是组成内核最为重要的文件。同时，arch/arm/Makefile 对 CORE_FILES 进行了扩充：
# arch/arm/Makefile
# If we have a machine-specific directory, then include it in the build.
MACHDIR := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS += $(MACHDIR)
CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS := arch/arm/lib/lib.a $(LIBS)

5） 编译信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定义的是编译的通用规则，具体到特定的场合，需要明确给出编译环境，编译环境就是在以上的变量中定义的。针对交叉编译的要求，定义了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定义了交叉编译器前缀 arm-linux-，表明所有的交叉编译工具都是以 arm-linux- 开头的，所以在各个交叉编译器工具之前，都加入了 $(CROSS_COMPILE)，以组成一个完整的交叉编译工具文件名，比如 arm-linux-gcc。
CFLAGS 定义了传递给 C 编译器的参数。
LINKFLAGS 是链接生成 vmlinux 时，由链接器使用的参数。LINKFLAGS 在 arm/*/Makefile 中定义，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds

6） 配置变量CONFIG_*
.config 文件中有许多的配置变量等式，用来说明用户配置的结果。例如 CONFIG_MODULES=y 表明用户选择了 Linux 内核的模块功能。
.config 被顶层 Makefile 包含后，就形成许多的配置变量，每个配置变量具有确定的值：y 表示本编译选项对应的内核代码被静态编译进 Linux 内核；m 表示本编译选项对应的内核代码被编译成模块；n 表示不选择此编译选项；如果根本就没有选择，那么配置变量的值为空。
2.3 Rules.make 变量
前面讲过，Rules.make 是编译规则文件，所有的 Makefile 中都会包括 Rules.make。Rules.make 文件定义了许多变量，最为重要是那些编译、链接列表变量。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目录下需要编译进 Linux 内核 vmlinux 的目标文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。
M_OBJS，MX_OBJS：本目录下需要被编译成可装载模块的目标文件列表。同样，MX_OBJS 中的 "X" 表明目标文件使用了 EXPORT_SYMBOL 输出符号。
O_TARGET，L_TARGET：每个子目录下都有一个 O_TARGET 或 L_TARGET，Rules.make 首先从源代码编译生成 O_OBJS 和 OX_OBJS 中所有的目标文件，然后使用 $(LD) -r 把它们链接成一个 O_TARGET 或 L_TARGET。O_TARGET 以 .o 结尾，而 L_TARGET 以 .a 结尾。

❹ linux怎么导出内核中的文件

linux内核之模块参数及导出符号
1. 模块参数
用 “mole_param （参数名，参数类型，参数读 / 写权限） ” 为模块定义一个参数，例如下列代码定义了 1 个整型参数和 1 个字符指针参数：
1 static char *book_name = "dissecting Linux Device Driver";
2 mole_param(book_name, charp, S_IRUGO);
3 static int book_num = 4000;
4 mole_param(book_num, int, S_IRUGO);
在装载内核模块时，用户可以向模块传递参数，形式为 “insmode 模块名 参数名 = 参数值，如果不传递，参数将使用模块内定义的缺省值。参数类型可以是 byte 、 short 、 ushort 、 int 、 uint 、 long 、 ulong 、 charp （字符指针）、 bool 或 invbool （布尔的反），在模块被编译时会将 mole_param 中声明的类型与变量定义的类型进行比较，判断是否一致。模块被加载后，在 /sys/mole/ 目录下将出现以此模块名命名的目录。在此模块的目录下还将出现 parameters 目录，其中包含一系列以参数名命名的文件节点，这些文件的权限值就是传入mole_param （）的 “参数读 / 写权限” ，而文件的内容为参数的值。
insmod命令加载模块后，通过查看 “/var/log/messages” 日志文件可以看到内核的输出：
# tail -n 2 /var/log/messages
tail -n 2表示输入文件的最后2行
2. 导出符号
Linux 的 “/proc/kallsyms” 文件对应着内核符号表，它记录了符号以及符号所在的内存地址。模块可以使用如下宏导出符号到内核符号表中：
EXPORT_SYMBOL( 符号名 );
EXPORT_SYMBOL_GPL( 符号名 );
导出的符号可以被其他模块使用，只需使用前声明一下即可。 EXPORT_SYMBOL_GPL （）只适用于包含 GPL许可权的模块。
如果符号名是“e_symbol”，从 “/proc/kallsyms” 文件中找出 e_symbol 的相关信息：
# grep e_symbol /proc/kallsyms
8000af1c t e_symbol [export_symb]

❺ linux模块编译后加载不成功

从dmesg的输出来看，内核已经export了一个同样的symbol，你加载的驱动再次输出一遍就有问题了。

可能原因：

1. usbnet模块可能在系统启动后已经加载了，你不需要手动再次加载。这个又可能由两个原因造成：（1）你在menuconfig中选择USBNET模块为[*]模式(驱动集成到内核)，而非[M]模式(驱动以模块方式动态插入内核)；（2）你已经选择了[M]模式，但是按照系统的默认配置在系统启动过程中会自动动态加载这个驱动，无需手动加载；

2. 虽然选择了USBNET模块并重新编译了内核，但是新编译的内核并没有更新到系统上，系统还是使用的老的内核。

现在你应该可以排除一下上面的猜测的几种可能原因吧？

❻ 如何在linux内核中保留一块内存不被系统分配

要想在内核中保留一个块内存，不被系统分配，而是只由自己使用，可以使用以下函数
reserve_bootmem(addr,size,flag）
这个函数的三个参数，addr是你要保留的地址，size就是要保留的大小，flag是标志位，要来确定是否检查你要保留的空间是否已经被保留了，它可以设置为两个值，BOOTMEM_DEFAULT和BOOTMEM_EXCLUSIVE，前者就是总是会返回0（也就是保留成功），而后者则会检查你所要保留的空间是否已经被保留了，若已经被保留了，则它返回失败（负数）

那么这个函数一般放在哪里使用过了，我们建议放到内核init/main.c中，在页表的建立之前进行保留，比如我们下面的代码，放在main中的start_kernel函数中，我们的内核是2.6.32
asmlinkage void __init start_kernel(void)
{
……
……
trap_init();

if(reserve_bootmem(0x41000000,0x100000,BOOTMEM_EXCLUSIVE) != 0){
printk("reserve fail----\n");
}
printk("we reserve boot meme of 0x41000000 for gps---------------------------------\n");

mm_init();
……
……
}
这样就保留了一个起始地址为0x41000000，大小为1M的空间

❼ 获取Linux内核未导出符号的几种方式

只有在内核中使用EXPORT_SYMBOL或EXPORT_SYMBOL_GPL导出的符号才能在内核模块中直接使用。然而，内核并没有导出所有的符号。例如，在3.8.0的内核中，do_page_fault就没有被导出。 而我的内核模块中需要使用do_page_fault，那么有那些方法呢？这些方法分别有什么优劣呢？ 下面以do_page_fault为例，一一进行分析： 修改内核，添加EXPORT_SYMBOL(do_page_fault)或EXPORT_SYMBOL_GPL(do_page_fault)。 这种方法适用于可以修改内核的情形。在可以修改内核的情况下，这是最简单的方式。 使用kallsyms_lookup_name读取 kallsyms_lookup_name本身也是一个内核符号，如果这个符号被导出了，那么就可以在内核模块中调用kallsyms_lookup_name("do_page_fault")来获得do_page_fault的符号地址。 这种方法的局限性在于kallsyms_lookup_name本身不一定被导出。 读取/boot/System.map-，再使用内核模块参数传入内核模块 System.map-是编译内核时产生的，它里面记录了编译时内核符号的地址。如果能够保证当前使用的内核与System.map-是一一对应的，那么从System.map-中读出的符号地址就是正确的。其中，kernel-version可以通过'uname -r'获得。 但是这种方法也有局限性，在模块运行的时候，System.map-文件不一定存在，即使存在也不能保证与当前内核是正确对应的。 读取/proc/kallsyms，再使用内核模块参数传入内核模块 /proc/kallsyms是一个特殊的文件，它并不是存储在磁盘上的文件。这个文件只有被读取的时候，才会由内核产生内容。因为这些内容是内核动态生成的，所以可以保证其中读到的地址是正确的，不会有System.map-的问题。 需要注意的是，从内核2.6.37开始，普通用户是没有办法从/proc/kallsyms中读到正确的值。在某些版本中，该文件为空。在较新的版本中，该文件中所有符号的地址均为0（除非/porc/sys/kernel/kptr_restrict 的值被设为0）。但是root用户是可以从/proc/kallsyms中读到正确的值的。好在加载模块也需要root权限，可以在加载模块时用脚本获取符号的地址。

❽ 如何在Linux内核源代码中增加EXPORT_SYMBOL_GPL宏

添加EXPORT_SYMBOL_GPL只是步骤之一，你还需要将func_xxx在头文件中申明，然后#include该头文件才能使用。

❾ 全局变量 与export symbol区别

symbol 意思是交易产品 如： eurusd xauusd
order 意思是订单 如：20121223(这是订单号码 以区别于订单的不同 )

他俩共同表示一个订单产品 （全部的还包括 time. type .price. s/l . t/p .profit. ）