操作系统管理软硬件资源，用户进程只能直接或间接的通过系统调用访问系统资源，而用户进程与内核运行于不同的权限空间，需要进行用户态到内核态的转变，这一转变是通过系统中断实现。现以getpid为例：

在用户态通过API接口编程如下：

getpid 为应用编程接口(API)函数，提供统一标准接口，实现是通过系统调用获得进程ID。
系统调用函数由唯一的调用号标识，x86构架下在文件 arch/x86/include/asm/unistd.h 指定，实现文件根据32位系统与64为系统的不同分别实现在相同目录的unistd_32.h和unistd_64.h文件，现通过64位系统分析，32位系统原理相同。

可以看到getpid系统调用号为 39， 当然这在不同的系统上并不一定相同，getpid API函数的封装正是封装了种种不同。

系统初始化时创建名为 sys_call_table 的表项，其中存储了系统调用函数，而__NR_*调用号正是表项索引，sys_call_table的定义 32构架位于 arch/x86/kernel/syscall_table_32.S，sys_call_table 为起始地址依次存储一系列函数地址。

64位构架位于arch/x86/kernel/syscall_64.c，这里干脆定义成了一个sys_call_ptr_t类型数组，其初始化由宏__SYSCALL完成。

系统调用时，根据 sys_call_table[__NR_getpid] 获得 sys_getpid 地址调用之。如此，我们便可通过修改 sys_call_table 的初始化和__NR_*的定义来增加自己的系统调用和修改原来系统调用的执行方式。

倘若增加我们自己的系统调用，那接下来一问题是我们如何调用？getpid函数由glibc库封装，接下来需要看如何直接调用该内核函数。当然，通过源码可以看到getpid的实现即为 sys_getpid 函数，但因为调用需要进行特权级的转变，所以直接调用sys_getpid函数是行不通的。