很自然的，下一个疑问接踵而至，－－模块里的其他函数如何被调用？比如我写的模块中除了 init_mole() 和cleanup_mole() 函数外，还写了一个 hello_world() 函数，简单的输出hello world到控制台，好，接下来就是这次分析的关键，前面我们强调了模块中的函数是由内核来调用的，除此之外没有别的机会使它被执行到。那如果我们的 hello_world() 函数不能被内核调用，这不就意味着它永远也不可能被执行到吗？确实是这样，换句话说，在这种情况下它就是一段垃圾代码，永无见天日之时。怎么样才能使我们的 hello_world() 函数被执行？显然，关键在于让内核认识它，即内核能找到它。那么，怎样才能使内核找到这个函数？再进一步的问题是，内核为什么要去找这个函数？
第一问的答案是，内核通过系统中特定的数据结构来找到函数的，当然，这意味着在你的模块程序中，仅仅写上 hello_world() 函数的代码是不够的，还应该再做几步工作：
a，首先，系统中的各类数据结构那么多，要使用哪个呢？这由你这个模块的注册性质决定，譬如你的模块是一个USB设备驱动模块，那么你就需要填写usb设备驱动程序的数据结构（通常数据结构都是结构体(struct)的形式）
struct usb_driver{第一项；第二项；第三项；.......}
这里的各项有些是字符串，有些是函数指针，具体请查资料。
b，把 hello_world() 的函数指针放进一个数据结构中。我们还是接着举usb设备驱动程序模块的例子吧，在它的数据结构usb_driver{}中，选一个恰好是函数指针的项，把 hello_world() 函数的指针放进去（通过函数名），再填满这个数据结构的其他部分（不想填的话就空着吧:P，用分号分隔即可）。
c，填完之后，回到第一问中，怎样使内核能够找到这个 hello_world() 函数？回头想想，当我们填完了数据结构，也就决定了我们所编的模块的性质，在此例中它是作为一个usb设备驱动模块，但是要让内核知道它的性质，还得通过执行usb设备驱动程序的系统注册函数 usb_register(struct usb_struct *drv)，向内核注册这个模块以及这个填好的数据结构。注意到了吧，注册函数的参数就是我们前面所填写的usb设备驱动模块的数据结构，也就是说，执行了这个注册函数之后，内核里就认识了这个模块，并且得到了 hello_world() 函数的指针！哈哈，这就为我们的 hello_world() 函数找到了生存的意义－－它有可能被执行了！（偶觉得，程序生存的意义就在于被执行，就跟偶们生存的意义在于编程序一样:P）
d，还得补充一下，usb_register(struct usb_struct *drv) 函数必须被放在 init_mole() 中，因为在注册这个决定模块性质的数据结构之前（短语太长，可约为这个数据结构），模块中可以被直接执行到的函数只有 init_mole() 和 cleanup_mole() 两个，如果不把握这个机会赶紧注册数据结构的话，那我们的 hello_world() 函数又要永不见天日了:(。
现在来看第二问，内核为什么要去找这个函数？还是用usb设备驱动模块来解释，其他类型的模块偶不了解，还请大虾们补充。对于usb设备驱动模块，内核找这个函数的原因当然是，用户程序对usb设备进行了某种操作，而这种操作需要usb设备驱动程序的函数来进行实现。我们前面的工作中已将这个usb设备驱动模块的数据结构注册进内核数据结构链表，内核根据我们这个模块对应的数据结构usb_driver的各项定义，找到对应用户要求的那个操作的那个函数。假设我们把 hello_world() 函数的指针放在usb_driver的 write() 选项中，那么当用户对usb设备进行写操作的时候，就调用了 hello_world() 函数，控制台屏幕上会打出hello world ，其他什么操作都没有，哈哈，一定很有趣。(这里我们假设此usb设备的驱动程序正好是我们编的那个）
自己的一点心得，大部分是凭空想像的，错误之处一定数不胜数，还请各位大虾费心批评指教！
『贰』 如何调用Linux内核函数
注意看这个文件
sysdeps/unix/sysv/linux/syscalls.list
里面记录着系统调用的名字和一些属性，具体我也没有研究过，不懂。
再看select的实现，很让人惊讶，一旦使用，结果就是“报错“。
int
__select (nfds, readfds, writefds, exceptfds, timeout)
int nfds;
fd_set *readfds;
fd_set *writefds;
fd_set *exceptfds;
struct timeval *timeout;
{
__set_errno (ENOSYS);
return -1;
}
libc_hidden_def (__select)
stub_warning (select)
weak_alias (__select, select)
这是因为glibc并没有实现系统调用，而是调用系统调用，
更进一步，连调用系统调用都没有一个个实现，而是使用了通用的办法，
理由很简单，所有的系统调用在linux内核头文件里都能找到，
所有的系统调用参数类型就那么几种，参数个数也是有限的，
因此没有必要针对所有的系统调用一一封装，
于是就有了这个list文件，自动生成调用系统调用的函数，
如果生成失败，也就是你看到的“报错”。
符号是有强弱的，当自动生成成功的时候，“报错”的弱符号就被忽略了。
当你在glibc中找到一个系统调用的封装源码，是以下原因，
1. 编译的目标系统不支持这个系统调用，所以自己用另一种方式实现了。
2. 这个系统调用无法使用通用的自动生成方式生成，用特化的方式覆盖。
3. 针对这个系统调用做了特别的优化。
4. 其它可能的原因。
具体可以留意
SYSCALL, PSEUDO, DO_CALL, INLINE_CALL 等名字
这两个文件是重点所在
sysdeps/unix/i386/sysdep.h
sysdeps/unix/i386/sysdep.S
要搞清楚具体的自动生成过程，恐怕得研究glibc自身的编译过程了
『叁』 在linux中 应用程序如何调用模块内的函数
楹
『肆』 红帽linux中C语言编程如何调用数学函数
红帽linux中C语言编程调用数学函数参考案例如下所示：
当需要调用函数的个数比较少时，可以直接在main函数中包含该文件，比如一个文件夹下包含add.c和main.c文件。
文件add.c定义两个整数相加的函数,code如下：#include
『伍』 linux 怎么调用内核导出的函数
Linux内核没有导出的函数不能调用，即使包含了头文件，也会出现符号未定义的警告，并在加载模块时失败。
以下是我的测试例子：
#include <linux/mole.h>
#include <linux/syscalls.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Linmiaohe");
MODULE_DESCRIPTION("try to evole sys_umount");
extern asmlinkage long sys_umount(char __user *name, int flags);
static int __init sys_umount_init(void)
{
sys_umount("./proc",0);
return 0;
}
static void __exit sys_umount_exit(void)
{
printk(KERN_INFO "***********sys_umount mole has been unregistered*************\n");
}
mole_init(sys_umount_init);
mole_exit(sys_umount_exit);
『陆』 在Linux下，在C中怎么调用C++的库函数
调用C++函数库，一般不能直接调用，需要将C++库转换成C接口输出，方可以使用C调用
将 C++ 函数声明为``extern "C"''（在你的 C++ 代码里做这个声明），然后调用它（在你的 C 或者 C++ 代码里调用）。例如：
// C++ code:
extern "C" void f(int);
void f(int i)
{
// ...
}
然后，你可以这样使用 f()：
/* C code: */
void f(int);
void cc(int i)
{
f(i);
/* ... */
}
当然，这招只适用于非成员函数。如果你想要在 C 里调用成员函数（包括虚函数），则需要提供一个简单的包装（wrapper）。例如：
// C++ code:
class C
{
// ...
virtual double f(int);
};
extern "C" double call_C_f(C* p, int i) // wrapper function
{
return p->f(i);
}
然后，你就可以这样调用 C::f()：
/* C code: */
double call_C_f(struct C* p, int i);
void ccc(struct C* p, int i)
{
double d = call_C_f(p,i);
/* ... */
}
如果你想在 C 里调用重载函数，则必须提供不同名字的包装，这样才能被 C 代码调用。例如：
// C++ code:
void f(int);
void f(double);
extern "C" void f_i(int i) { f(i); }
extern "C" void f_d(double d) { f(d); }
然后，你可以这样使用每个重载的 f()：
/* C code: */
void f_i(int);
void f_d(double);
void cccc(int i,double d)
{
f_i(i);
f_d(d);
/* ... */
}
注意，这些技巧也适用于在 C 里调用 C++ 类库，即使你不能（或者不想）修改 C++ 头文件。
再看下面的例子：
aa.cxx
#include "aa.h"
int sample::method()
{
cout<<"method is called!\n";
}
aa.h
#include
using namespace std;
class sample
{
public:
int method();
};
将上面的两个文件生成动态库libaa.so放到 /usr/lib目录下，编译命令如下
sudo g++ -fpic -shared -g -o /usr/lib/libaa.so aa.cxx -I ./
由于在C中不能识别类，所以要将上面类的成员函数封装成C接口函数输出，下面进行封装，将输出接口转换成C接口。
mylib.cxx
#include "add.h"
#ifndef _cplusplus
#define _cplusplus
#include "mylib.h"
#endif
int myfunc()
{
sample ss;
ss.method();
return 0;
}
mylib.h
#ifdef _cplusplus
extern "C"
{
#endif
int myfunc();
#ifdef _cplusplus
}
#endif
在linux下，gcc编译器并没用变量_cplusplus来区分是C代码还是C++代码，如果使用gcc编译器，这里我们可以自己定义一个变量_cplusplus用于区分C和C++代码，所以在mylib.cxx中定义了一个变量_cplusplus用于识别是否需要“extern "C"”将函数接口封装成C接口。但是如果使用g++编译器则不需要专门定义_cplusplus，编译命令如下：
g++ -fpic -shared -g -o mylib.so mylib.cxx -la -I ./
main.c
#include
#include
#include "mylib.h"
int
main()
{
int (*dlfunc)();
void *handle; //定义一个句柄
handle = dlopen("./mylib.so", RTLD_LAZY);//获得库句柄
dlfunc = dlsym(handle, "myfunc"); //获得函数入口
(*dlfunc)();
dlclose(handle);
return 0;
}
编译命令如下：
gcc -o main main.c ./mylib.so -ldl
下面就可以执行了。
需要说明的是，由于main.c 和 mylib.cxx都需要包含mylib.h，并且要将函数myfunc封装成C接口函数输出需要“extern "C"”，而C又不识别“extern "C"”，所以需要定义_cplusplus来区别处理mylib.h中的函数myfunc。
在main.c的main函数中直接调用myfunc（）函数也能执行，这里介绍的是常规调用库函数的方法。
『柒』 在linux中怎么运行脚本函数
1、同一脚本文件中的函数：
#!/bin/sh
function func1()
{
echo $1
}
func1 "Hello world!"
2、其它脚本文件中的函数：
func.sh文件内容如下（其内中定义了函数func1，需容要1个参数）：
#!/bin/sh
function func1()
{
echo $1
}
主程序脚本：
#!/bin/sh
. func.sh
func1 "Hello world!"
『捌』 Linux的库函数是如何调用内核函数的
看系统调用，还有库函数，以前一直不明白，总是以为 系统调用跟库函数是一样的，但是今天才知道是不一样的。
库函数也就是我们通常所说的应用编程接口API，它其实就是一个函数定义，比如常见read()、write()等函数说明了如何获得一个给定的服务，但是系统调用是通过软中断向内核发出一个明确的请求，再者系统调用是在内核完成的，而用户态的函数是在函数库完成的。
系统调用发生在内核空间，因此如果在用户空间的一般应用程序中使用系统调用来进行文件操作，会有用户空间到内核空间切换的开销。事实上，即使在用户空间使用库函数来对文件进行操作，因为文件总是存在于存储介质上，因此不管是读写操作，都是对硬件（存储器）的操作，都必然会引起系统调用。也就是说，库函数对文件的操作实际上是通过系统调用来实现的。例如C库函数fwrite()就是通过write()系统调用来实现的。
这样的话，使用库函数也有系统调用的开销，为什么不直接使用系统调用呢？这是因为，读写文件通常是大量的数据（这种大量是相对于底层驱动的系统调用所实现的数据操作单位而言），这时，使用库函数就可以大大减少系统调用的次数。这一结果又缘于缓冲区技术。在用户空间和内核空间，对文件操作都使用了缓冲区，例如用fwrite写文件，都是先将内容写到用户空间缓冲区，当用户空间缓冲区满或者写操作结束时，才将用户缓冲区的内容写到内核缓冲区，同样的道理，当内核缓冲区满或写结束时才将内核缓冲区内容写到文件对应的硬件媒介。
系统调用与系统命令：系统命令相对API更高一层，每个系统命令都是一个可执行程序，比如常用的系统命令ls、hostname等，比如strace ls就会发现他们调用了诸如open(),brk(),fstat(),ioctl()等系统调用。
系统调用是用户进程进入内核的接口层，它本身并非内核函数，但他是由内核函数实现的，进入系统内核后，不同的系统调用会找到各自对应的内核函数，这写内核函数被称为系统调用的“服务例程”。也可以说系统调用是服务例程的封装例程。