加了static的关键字，不同c文件中同名函数，不会报重定义。
关于头文件中的 static inline函数
头文件中常见static inline函数，于是思考有可能遇到的问题，如头文件经常会被包含会不会产生很多副本？网上说法不一。于是自己验证。 经过arm-none-eabi-gcc下测试后得出结论。
inline 关键字实际上仅是 建议内联并不强制内联，gcc中O0优化时是不内联的，即使是O2以上，如果该函数被作为函数指针赋值，那么他也不会内联，也必须产生函数实体，以获得该函数地址。经测试c文件中的仅inline函数即使Os优化也不内联，因为没有static，编译认他是全局的，因此像普通函数一样编译了，本c文件也一样通过 bl inline_func 这样的方式调用，不像网上别人说的，本c会内联，其他c文件则通过bl inline_func 方式。加入static 后则内联了。（Os优化等级测试）
所以在头文件中用inline时务必加入static，否则当inline不内联时就和普通函数在头文件中定义一样，当多个c文件包含时就会重定义。所以加入static代码健壮性高，如果都内联了实际效果上是一样的。（gcc下验证过O0级别includes.h中仅定义inline的函数，编译失败，Os编译成功）
为什么要在头文件中定义函数呢？
虽然知道了头文件中用inline函数时要加入static，但是为什么要在头文件中定义函数呢？
一些简单的封装接口函数，如 open() { vfs_open() } 仅仅是为了封装一个接口，我们不希望耗费一次函数调用的时间，解决方法一是宏，但是作为接口，宏不够清晰。那选择inline，但是如果在c文件中写
main.c
inline void open(void)
{
vfs_open();
}
头文件加声明，外部要使用则不会内联的，因为编译器有个原则，以c文件为单位进行逐个编译obj，每个c文件的编译是独立的，该c文件用到的外部函数都在编译时预留一个符号，只有等到所有obj生成后链接时才给这些符号地址（链接脚本决定地址），所以其他c文件编译时只会看到这个函数的声明而无法知道她的实体，就会像普通函数一样通过bl 一个函数地址，等链接的时候再填入该地址了，他做不到内联展开。
所以要内联则必须在每个用到它的c文件体现实体，那就只有在头文件了， 所以会把这类希望全局使用又希望增加效率的函数实现在头文件中static inline。
static inline 的坏处
因为inline 是C99才有的关键字，C89没有，有部分编译器不支持，或者部分支持，如支持__inline 或 __inline__等，所以我们一般会用一个宏定义inline 如：
#define INLINE static inline
不支持inline时：
#define INLINE static
但是这样如果编译器不支持inline 即意味着之前 static inline的函数全部被修改为 static，在头文件中写static会有什么后果呢？
经过测试果然和我们想的一样，每个c文件包含了该头文件后全部都有了该函数副本。这无疑增大了很多代码量。比如在include.h
这样的大头文件，几乎每个c文件我们都会包含他，相当于每一C文件都会加入一个 static void func(void){...} 实体。如果是函数宏则不会有这种问题，函数宏是没有实际代码的，没调用他时代码不存在。这就是头文件中用static inline 函数的坏处。但是可以通过优化解决，经过测试，O0优化下在头文件中定义static 函数包含该头文件的三个c文件的确都有了该函数，但是在Os优化下则只有调用了该函数的C文件才有实体。这是由编译器对static函数的特性决定的。总之他的法则和我们想的一致，就是头文件仅仅是单纯的展开，而每个C独立编译，不会因为知道其他个C文件定义了该函数，这个c文件就把他当外部bl了。
