linux内存池
㈠ 操作系统真象还原怎么样，操作系统真象还原好不好
当人按下笔记本开机键时.cpu的cs寄存器(基址)跟ip(偏移量)寄存器加电.被强制初始化为(jmp xxx:xxx) 跳转到bios所在的地址.
接着bios开机自检(这个不需要了解,只需了解最后跳转到0x7c00处即可.对于写kernel的人来说也是透明的.除非你是写bios的).它将自动从0盘1扇区加载mbr(主引导程序,512字节必须是以0x55,0xaa结尾..如果不够,可以用times 510-($-$$) db 0.很多都是这样定义的.) 加载到0x7c00处.因为bios执行的最后一条指令时jmp 0x7c00处.
紧接着用汇编编写mbr.. Mbr的功能是也是从硬盘读取loader(加载内核的程序). Loader存放的位置跟加载到的内存地址由自己决定...mbr就是根据硬盘提供的接口(,0x1f2~0x1f7)读取内容.movsb之类的指令复制到内存.最后一个jmp指令跳转到loader加载的地址
(注:以上的地址都是物理地址)
紧接着编写loader程序(加载内核程序).在loader程序中.我打算通过bios中断获取整个计算机的物理内存.并且进入保护模式.因此在loader.S中..我要定义代码段,跟数据段.显示段(显示字符.一般是0xb8000位置.)还是定义页表(采用二级页表
--------------------------------------------------------------------
数据段的内容是定义
全局描述符表跟代码段数据段显示段描述符..还有定义各种段选择子.位置自己定义.(这里我深深体会到了intel为了跟前代保持兼容多么拼了..定义的描述符真的好恶心.....的说
代码段:
通过int 15h中断获取物理内存.保存在某一固定物理位置.紧接着打开A20 Gate.加载gdt(全局描述符表).将cpu的cr0的pe位置置为1(由此进入保护模式,cs,ds的值不再是段基址.而是段选择子)
紧接着将各种段选择子复制到段寄存器中(保护模式)................紧接着..就开始创建二级页表(位置.自己固定.不过我看知乎上..一般是在1m物理内存以下).. .创建好以后.用sgdt将描述符表地址(现在是物理地址)加载到寄存器中(注意在创建页目录表的时候...一般我看知乎是将地址映射到0xc000000处.(windows是采用这地址)........开启映射前后....内核的虚拟地址(一个原本的物理地址变成了线性地址),还有0xc000000..这2个线性地址都要映射到1m以下物理内存.等于768页目录跟0页目录(寻址方式.一个虚拟地址的前10位为页目录表索引.中间10位为页表索引.最后10位为页框偏移量)都指向一个页表.
紧接着栈指针也加上0xc000000处...为了映射).紧接着将cr0寄存器的31位置为1,表示开启分页机制..注意之前的加载的gdt是物理地址.现在改为线性地址.需要重新加载(其实就是原来的地址+0xc000000处..一个lgdt[gdt_ptr].ok...最后.......跳转到内核所在的地址(自己定义内核所在的地址).......内核编写需要了解elf(格式.推荐<<程序员的自我修养>>..我没看..只是网友推荐罢了).定义elf头.程序头表.节头表.内核大小偏移量.等这些定义好了后.就可以加载内核了.一jmp指令就搞定了.....其实加载的内核一开始就是int main(void){while(1); return 0}....没办法.啥系统调用都没实现.啥都要自己实现....没办法...轮子是一步一步造出来的嘛.
保护模式的话.主要体现在cpu的特权级...有了操作系统后.其实一个程序分为用户部分跟内核部分(权限不同..一般用户部分是3特权级,0是最高特权级.还有IO特权级这个就懒得解释了都一样.哪些端口可以访问权限).........主要从低特权级转移到高特权级(用户态到内核态转换)只能通过各种门(任务们,调用门.陷阱门.中断门等) 条件.访问门时 cpl<=dpl[门] &cpl>=dpl[段] 这个表示r3可以使用内核服务访问段max(cpl,rpl)<=dpl[段] 这样就可以访问段. 从高特权级向低特权级返回的话.用ret弹出ip.或者retf cs:ip.......
PS:门描述符也是定义在GDT中.Call 调用门选择子.参数就是选择子.选择子找到门描述符.结果门描述符定义了代码段的基址(段选择子)跟偏移量..接着..找到内核例程.............坑爹.....对了..从用户态到内核态.所用的代码段跟数据段权限是不同的.so.所对应的栈也不同.有个TSS(任务状态段就是用来保存上下文的..其实一般只保存ss:sp... TSS效率比较低.linux只用了一个TSS并不切换).
紧接着要了解函数调用约定.查了wiki.c语言用的是cdecl约定(eax,edx,ecx由调用者保存.其他是被调用者保存.返回值在eax中.由调用者清理栈空间(就是esp+xx.实际不能说清理),参数压栈从右到左.例子自己google查吧
紧接着...卧槽..总该用c语言了吧.....之前一直用汇编..开始实现打印hello os.然后就....想顺便学学内联汇编..结果我了个大去...内联汇编是.AT&T汇编语法跟x86汇编有很大不同.没办法.....google对比下.一个一个指令弄呗......接着..想实现一个printf函数..除了 bios中断....算了..自己实现..一查显卡端口控制..我勒个去..吓得半死..VGA寄存器..一大堆..从0懒得实现了......从github抄了别人实现可以光标跟踪的输出函数....不过也懂得其原理.一个读入写出寄存器一个控制寄存器...忘了....不过不重要.略过
紧接着实现中断......哥现在理解的所谓操作系统就是由中断驱动的.所谓的时间片不过是(时间中断产生的间隔时间罢了),等于躺着被调用的代码....中断根据网上资料cpu提供统一的接口为中断信号的公共路线..毕竟没则么多引脚.分为INTR跟NMI(灾难性错误).只管INTR就可以了.编写中断向量表(IDT).并且要保存在IDTR寄存器中.一般发出的信号就是中断向量号.这个号就是中断描述符表的索引,加上IDTR得到某中断描述符具体位置.接着.中断描述符保存中断处理程序的选择子跟偏移量..接着道GDT中找.到代码段的起始地址再加上偏移量(保存在IDT描述符中).最后还要了解8259A(外设的可屏蔽中断的代理.包括键盘.时间中断).编程设置它初始化.设置主片葱片级联方式........最后编写中断处理程序(参考 unix v6实现)..最后时间中断....网上一般采用计数器8253设置时间中断发生的频率.提速降速.随你便.2333333 接下来就是哥认为最兴奋的一笔.内存管理.通过位图映射来管理内存.位图的每一位映射一个4k大小的页.0表示该页未被使用.1表示已经被使用..位图相关处理函数写好后.正式开始规划内存了..
内存池的划分参考知乎某大牛说的答案.内存池分为虚拟内存池跟物理内存池.虚拟内存池管理虚拟地址.物理内存管理物理地址.......................我的话把物理内存一半给用户,一半给内核........虚拟内存池(每个用户进程都有一个).但内核虚拟地址只有一个(因为内核只有一个.对不对).有关位图的位置就是自己定义了.......虚拟地址映射物理地址.完成此操作就OK了(不过这里还没实现用户进程.so.只完成了内核相关虚拟地址映射.).其实malloc的..就是用链表管理更小的内存块.我这里最小的内存块...是4k...太大了..要很小(16字节.32字节.64字节.等).用内存块描述符管理更小相同规格的内存块.用块描述符链表将整个链接起来.
接下来实现线程..线程哎..说实话..也没啥.就一个执行流(有自己的栈.寄存器映像)..不过只能使用进程的虚拟地址(没资源).没啥很高深的..总之进程跟线程就是人为搞的代码块.各种状态也是人自己划分的.自圆其说.2333333333333.(注:我实现的是内核线程.不然..还要自己实现.用户线程调度..太麻烦了.不然这些都交给内核调度岂不美哉.
一开始呢.要实现PCB(不然..你的上下文保存在哪?.TSS,cpu只自动获取ss:sp,需要自己手动压入当前各种寄存器状态.因为如果用TSS(在内存)切换效率相当低.so.基本linux也不用TSS).TCB分为2部分(一个是被中断打断的栈空间.一个是线程自己空间,说明一点.一般发现线程基本都是个函数.函数的地址....嘿嘿没错就是当运行这个线程时cs:ip指向函数地址.就通过赋值语句.)忘说了.pcb需要占用一页大小内存.so.从内核内存池中申请一页大小.)...有关内核调度.只不过时间中断处理程序调用了scele函数(开始要判断是否该线程时间片用完了没).........用链表管理就绪队列.跟总队列..其实我搞的这简单内核最复杂不过是用来链表罢了.所以写个简单内核..初中生差不多都可以完成.当然linus那种大神....不是一般人可以达到的.
最后说说锁...保证原子性(不能被打断).其实最基本的就是一条关中断cli汇编指令.实现的.只不过封装了一层..哎.....没想到这么简单吧
最后说说系统调用(参考linux最初版本,实现的这功能其实现在已经被弃用了)...mov eax,子功能号. Int 号码.调用syscall_table[eax].(其中system_table保存的是子功能的函数名(地址)........)...最后就是无聊的抄...系统调用实现的代码了.............
最后要实现用户进程.用户进程最主要区别就是特权级是最低特权级3.还有有自己的虚拟地址.流程(向内核申请一页大小.创建pcb.初始化pcb.创建管理虚拟地址用户位图...紧接着创建线程...线程中创建页目录表.添加到就绪队列中...等待调度......这里最关键是要让用户进程在特权级3下运行..so.其用户进程所使用的代码段跟数据段都必须是3特权级......完结.
参考<<一个操作系统的实现>>,<<x86从实模式到保护模式>>.<<现代操作系统>>
(上面其实已经写的省略了很多.这是我一口气写完的..可能忘了很多....如果有啥不对.请求指正)
文件系统跟shell部分.(...文件系统打算照搬unix v6的..我读都没读完..shell参考学院的教材(unix/linux编程实践)......
好了.很惭愧.只做了一点微小的工作.谢谢大家.
㈡ 研究生课题 linux内核怎么样 2015
图2-1显示了基于x86计算机Linux系统的启动顺序。第一步是BIOS从启动设备中导入主引导记录(MBR)，接下来MBR中的代码查看分区表并从活动分区读取GRUB、LILO或SYSLINUX等引导装入程序，之后引导装入程序会加载压缩后的内核映像并将控制权传递给它。内核取得控制权后，会将自身解压缩并投入运转。
基于x86的处理器有两种操作模式：实模式和保护模式。在实模式下，用户仅可以使用1 MB内存，并且没有任何保护。保护模式要复杂得多，用户可以使用更多的高级功能(如分页)。CPU 必须中途将实模式切换为保护模式。但是，这种切换是单向的，即不能从保护模式再切换回实模式。
内核初始化的第一步是执行实模式下的汇编代码，之后执行保护模式下init/main.c文件(上一章修改的源文件)中的 start_kernel()函数。start_kernel()函数首先会初始化CPU子系统，之后让内存和进程管理系统就位，接下来启动外部总线和 I/O设备，最后一步是激活初始化(init)程序，它是所有Linux进程的父进程。初始化进程执行启动必要的内核服务的用户空间脚本，并且最终派生控制台终端程序以及显示登录(login)提示。
图2-1 基于x86硬件上的Linux的启动过程
本节内的3级标题都是图2-2中的一条打印信息，这些信息来源于基于x86的笔记本 电脑的Linux启动过程。如果在其他体系架构上启动内核，消息以及语义可能会有所不同。
2.1.1 BIOS-provided physical RAM map
内核会解析从BIOS中读取到的系统内存映射，并率先将以下信息打印出来：
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
...
BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
实模式下的初始化代码通过使用BIOS的int 0x15服务并执行0xe820号函数(即上面的BIOS-e820字符串)来获得系统的内存映射信息。内存映射信息中包含了预留的和可用的内存，内核将随后使用这些信息创建其可用的内存池。在附录B的B.1节，我们会对BIOS提供的内存映射问题进行更深入的讲解。
图2-2 内核启动信息
2.1.2 758MB LOWMEM available
896 MB以内的常规的可被寻址的内存区域被称作低端内存。内存分配函数kmalloc()就是从该区域分配内存的。高于896 MB的内存区域被称为高端内存，只有在采用特殊的方式进行映射后才能被访问。
在启动过程中，内核会计算并显示这些内存区内总的页数。
2.1.3 Kernel command line: ro root=/dev/hda1
Linux的引导装入程序通常会给内核传递一个命令行。命令行中的参数类似于传递给C程序中main()函数的argv[]列表，唯一的不同在于它们是传递给内核的。可以在引导装入程序的配置文件中增加命令行参数，当然，也可以在运行过程中修改引导装入程序的提示行[1]。如果使用的是GRUB 这个引导装入程序，由于发行版本的不同，其配置文件可能是/boot/grub/grub.conf或者是/boot/grub/menu.lst。如果使用的是LILO，配置文件为/etc/lilo.conf。下面给出了一个grub.conf文件的例子(增加了一些注释)，看了紧接着title kernel 2.6.23的那行代码之后，你会明白前述打印信息的由来。
default 0 #Boot the 2.6.23 kernel by default
timeout 5 #5 second to alter boot order or parameters
title kernel 2.6.23 #Boot Option 1
#The boot image resides in the first partition of the first disk
#under the /boot/ directory and is named vmlinuz-2.6.23. 'ro'
#indicates that the root partition should be mounted read-only.
kernel (hd0,0)/boot/vmlinuz-2.6.23 ro root=/dev/hda1
#Look under section "Freeing initrd memory:387k freed"
initrd (hd0,0)/boot/initrd
#...
命令行参数将影响启动过程中的代码执行路径。举一个例子，假设某命令行参数为bootmode，如果该参数被设置为1，意味着你希望在启动过程中打印一些调试信息并在启动结束时切换到runlevel的第3级(初始化进程的启动信息打印后就会了解runlevel的含义);如果bootmode 参数被设置为0，意味着你希望启动过程相对简洁，并且设置runlevel为2。既然已经熟悉了init/main.c文件，下面就在该文件中增加如下修改：
static unsigned int bootmode = 1 ;
static int __init
is_bootmode_setup( char * str)
{
get_option( & str, & bootmode);
return 1 ;
}
/* Handle parameter "bootmode=" */
__setup( " bootmode= " , is_bootmode_setup);
if (bootmode) {
/* Print verbose output */
/* ... */
}
/* ... */
/* If bootmode is 1, choose an init runlevel of 3, else
switch to a run level of 2 */
if (bootmode) {
argv_init[ ++ args] = " 3 " ;
} else {
argv_init[ ++ args] = " 2 " ;
}
/* ... */
请重新编译内核并尝试运行新的修改。
2.1.4 Calibrating delay...1197.46 BogoMIPS (lpj=2394935)
在启动过程中，内核会计算处理器在一个jiffy时间内运行一个内部的延迟循环的次数。jiffy的含义是系统定时器2个连续的节拍之间的间隔。正如所料，该计算必须被校准到所用CPU的处理速度。校准的结果被存储 在称为loops_per_jiffy的内核变量中。使用loops_per_jiffy的一种情况是某设备驱动程序希望进行小的微秒级别的延迟的时候。
为了理解延迟—循环校准代码，让我们看一下定义于init/calibrate.c文件中的calibrate_ delay()函数。该函数灵活地使用整型运算得到了浮点的精度。如下的代码片段(有一些注释)显示了该函数的开始部分，这部分用于得到一个 loops_per_jiffy的粗略值：
loops_per_jiffy = ( 1 << 12 ); /* Initial approximation = 4096 */
printk(KERN_DEBUG “Calibrating delay loop...“);
while ((loops_per_jiffy <<= 1 ) != 0 ) {
ticks = jiffies; /* As you will find out in the section, “Kernel
Timers," the jiffies variable contains the
number of timer ticks since the kernel
started, and is incremented in the timer
interrupt handler */
while (ticks == jiffies); /* Wait until the start of the next jiffy */
ticks = jiffies;
/* Delay */
__delay(loops_per_jiffy);
/* Did the wait outlast the current jiffy? Continue if it didn't */
ticks = jiffies - ticks;
if (ticks) break ;
}
loops_per_jiffy >>= 1 ; /* This fixes the most significant bit and is
the lower-bound of loops_per_jiffy */
上述代码首先假定loops_per_jiffy大于4096，这可以转化为处理器速度大约为每秒100万条指令，即1 MIPS。接下来，它等待jiffy被刷新(1个新的节拍的开始)，并开始运行延迟循环__delay(loops_per_jiffy)。如果这个延迟循环持续了1个jiffy以上，将使用以前的loops_per_jiffy值(将当前值右移1位)修复当前loops_per_jiffy的最高位;否则，该函数继续通过左移loops_per_jiffy值来探测出其最高位。在内核计算出最高位后，它开始计算低位并微调其精度：
loopbit = loops_per_jiffy;
/* Graally work on the lower-order bits */
while (lps_precision -- && (loopbit >>= 1 )) {
loops_per_jiffy |= loopbit;
ticks = jiffies;
while (ticks == jiffies); /* Wait until the start of the next jiffy */
ticks = jiffies;
/* Delay */
__delay(loops_per_jiffy);
if (jiffies != ticks) /* longer than 1 tick */
loops_per_jiffy &= ~ loopbit;
}
上述代码计算出了延迟循环跨越jiffy边界时loops_per_jiffy的低位值。这个被校准的值可被用于获取BogoMIPS(其实它是一个并非科学的处理器速度指标)。可以使用BogoMIPS作为衡量处理器运行速度的相对尺度。在1.6G Hz 基于Pentium M的笔记本 电脑上，根据前述启动过程的打印信息，循环校准的结果是：loops_per_jiffy的值为2394935。获得BogoMIPS的方式如下：
BogoMIPS = loops_per_jiffy * 1秒内的jiffy数 * 延迟循环消耗的指令数（以百万为单位）
= ( 2394935 * HZ * 2 ) / ( 1000000 )
= ( 2394935 * 250 * 2 ) / ( 1000000 )
= 1197.46 （与启动过程打印信息中的值一致）
在2.4节将更深入阐述jiffy、HZ和loops_per_jiffy。
2.1.5 Checking HLT instruction
由于Linux内核支持多种硬件平台，启动代码会检查体系架构相关的bug。其中一项工作就是验证停机(HLT)指令。
x86处理器的HLT指令会将CPU置入一种低功耗睡眠模式，直到下一次硬件中断发生之前维持不变。当内核想让CPU进入空闲状态时(查看 arch/x86/kernel/process_32.c文件中定义的cpu_idle()函数)，它会使用HLT指令。对于有问题的CPU而言，命令行参数no-hlt可以禁止HLT指令。如果no-hlt被设置，在空闲的时候，内核会进行忙等待而不是通过HLT给CPU降温。
当init/main.c中的启动代码调用include/asm-your-arch/bugs.h中定义的check_bugs()时，会打印上述信息。
2.1.6 NET: Registered protocol family 2
Linux套接字(socket)层是用户空间应用程序访问各种网络 协议的统一接口。每个协议通过include/linux/socket.h文件中定义的分配给它的独一无二的系列号注册。上述打印信息中的Family 2代表af_inet(互联网协议)。
启动过程中另一个常见的注册协议系列是AF_NETLINK(Family 16)。网络链接套接字提供了用户进程和内核通信 的方法。通过网络链接套接字可完成的功能还包括存取路由表和地址解析协议(ARP)表(include/linux/netlink.h文件给出了完整的用法列表)。对于此类任务而言，网络链接套接字比系统调用更合适，因为前者具有采用异步机制、更易于实现和可动态链接的优点。
内核中经常使能的另一个协议系列是AF_Unix或Unix-domain套接字。X Windows等程序使用它们在同一个系统上进行进程间通信。
2.1.7 Freeing initrd memory: 387k freed
initrd是一种由引导装入程序加载的常驻内存的虚拟磁盘映像。在内核启动后，会将其挂载为初始根文件系统，这个初始根文件系统中存放着挂载实际根文件系统磁盘分区时所依赖的可动态连接的模块。由于内核可运行于各种各样的存储控制器硬件平台上，把所有可能的磁盘驱动程序都直接放进基本的内核映像中并不可行。你所使用的系统的存储设备的驱动程序被打包放入了initrd中，在内核启动后、实际的根文件系统被挂载之前，这些驱动程序才被加载。使用 mkinitrd命令可以创建一个initrd映像。
2.6内核提供了一种称为initramfs的新功能，它在几个方面较initrd更为优秀。后者模拟了一个磁盘(因而被称为 initramdisk或initrd)，会带来Linux块I/O子系统的开销(如缓冲);前者基本上如同一个被挂载的文件系统一样，由自身获取缓冲 (因此被称作initramfs)。
不同于initrd，基于页缓冲建立的initramfs如同页缓冲一样会动态地变大或缩小，从而减少了其内存消耗。另外，initrd要求你的内核映像包含initrd所使用的文件系统(例如，如果initrd为EXT2文件系统，内核必须包含EXT2驱动程序)，然而initramfs不需要文件系统支持。再者，由于initramfs只是页缓冲之上的一小层，因此它的代码量很小。
用户可以将初始根文件系统打包为一个cpio压缩包[1]，并通过initrd=命令行参数传递给内核。当然，也可以在内核配置过程中通过 INITRAMFS_SOURCE选项直接编译进内核。对于后一种方式而言，用户可以提供cpio压缩包的文件名或者包含initramfs的目录树。在启动过程中，内核会将文件解压缩为一个initramfs根文件系统，如果它找到了/init，它就会执行该顶层的程序。这种获取初始根文件系统的方法对于嵌入式系统而言特别有用，因为在嵌入式系统中系统资源非常宝贵。使用mkinitramfs可以创建一个initramfs映像，查看文档 Documentation/filesystems/ramfs- rootfs-initramfs.txt可获得更多信息。
在本例中，我们使用的是通过initrd=命令行参数向内核传递初始根文件系统cpio压缩包的方式。在将压缩包中的内容解压为根文件系统后，内核将释放该压缩包所占据的内存(本例中为387 KB)并打印上述信息。释放后的页面会被分发给内核中的其他部分以便被申请。
在嵌入式系统开发过程中，initrd和initramfs有时候也可被用作嵌入式设备上实际的根文件系统。
2.1.8 io scheler anticipatory registered (default)
I/O调度器的主要目标是通过减少磁盘的定位次数来增加系统的吞吐率。在磁盘定位过程中，磁头需要从当前的位置移动到感兴趣的目标位置，这会带来一定的延迟。2.6内核提供了4种不同的I/O调度器：Deadline、Anticipatory、Complete Fair Queuing以及NOOP。从上述内核打印信息可以看出，本例将Anticipatory 设置为了默认的I/O调度器。
2.1.9 Setting up standard PCI resources
启动过程的下一阶段会初始化I/O总线和外围控制器。内核会通过遍历PCI总线来探测PCI硬件，接下来再初始化其他的I/O子系统。从图2-3中我们会看到SCSI子系统、USB控制器、视频 芯片(855北桥芯片组信息中的一部分)、串行端口(本例中为8250 UART)、PS/2键盘 和鼠标 、软驱 、ramdisk、loopback设备、IDE控制器(本例中为ICH4南桥芯片组中的一部分)、触控板、以太网控制器(本例中为e1000)以及PCMCIA控制器初始化的启动信息。图2-3中 符号指向的为I/O设备的标识(ID)。
图2-3 在启动过程中初始化总线和外围控制器
本书会以单独的章节讨论大部分上述驱动程序子系统，请注意如果驱动程序以模块的形式被动态链接到内核，其中的一些消息也许只有在内核启动后才会被显示。
2.1.10 EXT3-fs: mounted filesystem
EXT3文件系统已经成为Linux事实上的文件系统。EXT3在退役的EXT2文件系统基础上增添了日志层，该层可用于崩溃后文件系统的快速恢复。它的目标是不经由耗时的文件系统检查(fsck)操作即可获得一个一致的文件系统。EXT2仍然是新文件系统的工作引擎，但是EXT3层会在进行实际的磁盘改变之前记录文件交互的日志。EXT3向后兼容于EXT2，因此，你可以在你现存的EXT2文件系统上加上EXT3或者由EXT3返回到EXT2 文件系统。
EXT3会启动一个称为kjournald的内核辅助线程(在接下来的一章中将深入讨论内核线程)来完成日志功能。在EXT3投入运转以后，内核挂载根文件系统并做好“业务”上的准备：
EXT3-fs: mounted filesystem with ordered data mode
kjournald starting. Commit interval 5 seconds
VFS: Mounted root (ext3 filesystem).
2.1.11 INIT: version 2.85 booting
所有Linux进程的父进程init是内核完成启动序列后运行的第1个程序。在init/main.c的最后几行，内核会搜索一个不同的位置以定位到init：
if (ramdisk_execute_command) { /* Look for /init in initramfs */
run_init_process(ramdisk_execute_command);
}
if (execute_command) { /* You may override init and ask the kernel
to execute a custom program using the
"init=" kernel command-line argument. If
you do that, execute_command points to the
specified program */
run_init_process(execute_command);
}
/* Else search for init or sh in the usual places .. */
run_init_process( " /sbin/init " );
run_init_process( " /etc/init " );
run_init_process( " /bin/init " );
run_init_process( " /bin/sh " );
panic( " No init found. Try passing init= option to kernel. " );
init会接受/etc/inittab的指引。它首先执行/etc/rc.sysinit中的系统初始化脚本，该脚本的一项最重要的职责就是激活对换(swap)分区，这会导致如下启动信息被打印：
Adding 1552384k swap on /dev/hda6
让我们来仔细看看上述这段话的意思。Linux用户进程拥有3 GB的虚拟地址空间(见2.7节)，构成“工作集”的页被保存在RAM中。但是，如果有太多程序需要内存资源，内核会释放一些被使用了的RAM页面并将其存储到称为对换空间(swap space)的磁盘分区中。根据经验法则，对换分区的大小应该是RAM的2倍。在本例中，对换空间位于/dev/hda6这个磁盘分区，其大小为1 552 384 KB。
接下来，init开始运行/etc/rc.d/rcX.d/目录中的脚本，其中X是inittab中定义的运行级别。runlevel是根据预期的工作模式所进入的执行状态。例如，多用户文本模式意味着runlevel为3，X Windows则意味着runlevel为5。因此，当你看到INIT: Entering runlevel 3这条信息的时候，init就已经开始执行/etc/rc.d/rc3.d/目录中的脚本了。这些脚本会启动动态设备命名子系统(第4章中将讨论 udev)，并加载网络、音频、存储设备等驱动程序所对应的内核模块：
Starting udev: [ OK ]
Initializing hardware... network audio storage [Done]
...
最后，init发起虚拟控制台终端，你现在就可以登录了。
㈢ linux内存池能分配连续物理内存吗
处理器通过地址访问内存单元，程序中用到的基址加偏移地址是线性地址，需要通过MMU将虚拟地址映射成物理地址。这给分配和释放内存带来方便:1)物理地址不连续的空间可以映射为逻辑上连续的虚拟地址。2)进程可以获得比实际内存大的"空间"，虚拟内存使得进程在这种情况下仍可正常运行。
linux内核为驱动程序提供了一致的内存管理接口，因此不用考虑不同体系结构如何管理内存的。
在linux内核中分配内存用kmalloc和kfree。
kmalloc分配时可以被阻塞，且不对所获得的区域清零。它分配的区域在物理内存中也是连续的。
原型:
#include<linux/slab.h>
void *kmalloc(size_t size,int flags); //参数为分配大小及分配标志
flags参数:
GFP_KERNEL:内核内存通用分配方法，表示内存分配是由运行在内核空间的进程执行的。可休眠，所以使用GFP_KERNEL分配内存的函数必须是可重入的。
GFP_ATOMIC:用于在中断处理例程或者运行在进程上下文之外的代码中分配内存，不可休眠。内核通常会为原子性的分配预留一些空闲页面。
所有标志定义在 <linux/gfp.h>中。
size参数:
内核是基于页技术分配内存，以最佳的利用系统的RAM。
linux处理内存分配的方法是:创建一系列的内存对象池，每个池的内存大小事固定的，处理分配请求时，就直接在包含足够大的内存块中传递一个整款给请求者。内核只能分配一些预定义的固定大小的字节数组。kmalloc能处理的的最小内存块是32或者64，不大于128KB。
内存区段:
linux内核把内存分为3个区段:可用于DMA的内存，常规内存以及高端内存。kmalloc不能分配高端内存。内存区段在mm/page_alloc.c中实现。区段的初始化在对应的arch树下的mm/init.c中。
后备高速缓存 (lookaside cache)
内核中普通对象进行初始化所需的时间超过了对其进行分配和释放所需的时间，因此不应该将内存释放回一个全局的内存池，而是将内存保持为针对特定目而初始化的状态。例如，如果内存被分配给了一个互斥锁，那么只需在为互斥锁首次分配内存时执行一次互斥锁初始化函数（mutex_init）即可。后续的内存分配不需要执行这个初始化函数，因为从上次释放和调用析构之后，它已经处于所需的状态中了。
linux2.6中USB和SCSI驱动程序使用了这种高速缓存，是为一些反复使用的块增加某些特殊的内存池。后背高速缓存管理也叫slab分配器，相关函数和类型在<linux/slab.h>中申明。
slab分配器实现高速缓存具有kmem_cache_t类型。
kmem_cache_t * kmem_cache_create( const char *name, size_t size, size_t align,
unsigned long flags;
void (*constructor)(void*,kmem_cache_t *, unsigned long),
void (*destructor)(void*, kmem_cache_t *, unsigned long));
用于创建一个新的高速缓存对象。
constructor用于初始化新分配的对象，destructor用于清除对象。
一旦某个对象的高速缓存被创建以后，就可以调用kmem_cache_alloc从中分配内存对象。
void * kmem_cache_alloc(kmem_cache_t *cache,int flags);
释放内存对象使用kmem_cache_free
void kmem_cache_free(kmem_cache_t *cache,const void *obj);
在内存空间都被释放后，模块被卸载前，驱动程序应当释放他的高速缓存。
int kmem_cache_destory(kmem_cache_t *cache);
要检查其返回状态，如果失败，表明莫块中发生了内存泄露。
基于slab的高速缓存scullc
kmem_cache_t *scullc_cache;
scullc_cache=kmem_cache_creat("scullc",scullc_quantum,0,SLAB_HWCACHE_ALIGN,NULL,NULL);
if(!scullc_cache)
{
scullc_cleanup();
return -ENOMEM;
}
if(!dpte->data[s_pos])
{
dptr->data[s_pos]=kmem_cache_alloc(scullc_cache,GFP_KERNEL);
if(!dptr->data[s_pos])
goto nomem;
memset(dptr->data[s_pos],0,scullc_quantum);
}
for(i=0;i<qset;i++)
{
if(dptr->data[i])
kmem_cache_free(scullc_cache,dptr->data[i]);
}
if(scullc_cache)
kmem_cache_destory(scullc_cache);
内存池:
内核中有些地方的内存分配是不允许失败的，为确保能分配成功，内核建立一种称为内存池的抽象，他试图始终保持空闲状态，以便紧急情况使用。
mempool_t * mempool_creat(int min_nr,
mempool_alloc_t *alloc_fn, //对象分分配 mempool_alloc_slab
mempool_free_t *free_fn, //释放 mempool_free_slab
void *pool_data);
可以用如下代码来构造内存池
cache=kmem_cache_creat(...); //创建一个高速缓存
pool=mempool_creat(MY_POOL_MINIMUM,mempool_alloc_slab,mempool_free_slab,cache);//建立内存池对象
void *mempool_alloc(mempool_t *poll,int gfp_mask);//分配对象
void *mempool_free(void *element,mempool_t *poll);//释放对象
void mempool_destroy(mempool_t *poll);//销毁内存池
注意:mempool会分配一些内存块，空闲且不会被用到，造成内存的大量浪费。所以一般情况不要用内存池。
㈣ linux 下怎么优化mysql占用内存
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
为了保持高效的分配，分配器通常会预先向操作系统申请一块内存，当用户程序申请和释放内存的时候，分配器会将这些内存管理起来，并通过一些算法策略来判断是否将其返回给操作系统。这样做的最大好处就是可以避免用户程序频繁的调用系统来进行内存分配，使用户程序在内存使用上更加高效快捷。
关于 ptmalloc 的内存分配原理，个人也不是非常了解，这里就不班门弄斧了，有兴趣的同学可以去看下华庭的《glibc 内存管理 ptmalloc 源代码分析》【文末链接】。
关于如何选择这三种内存分配器，网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。因为 ptmalloc 的主要问题其实是内存浪费、内存碎片、以及加锁导致的性能问题，而 jemalloc 与 tcmalloc 对于内存碎片、多线程处理优化的更好。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
㈤ dpdk 技术 可否 应用于linux
DPDK主要使用了UIO、HUGEPAGE和CPU Affinity机制三个技术点来提高高速网络数据的处理性能。
UIO是实现用户空间下驱动程序的支撑机制，DPDK使用UIO机制使网卡驱动程序(主要是intel自身的千兆igb与万兆ixgbe驱动程序)运行在用户态，并采用轮询和零拷贝方式从网卡收取报文，提高收发报文的性能。
HUGEPAGE的主要好处是通过利用大内存页提高内存的使用效率，DPDK在HUGEPAGE机制上构建内存管理系统，提高应用程序处理报文的性能。
CPU Affinity机制主要是让各个CPU各自干自己的事情，DPDK使用CPU Affinity机制将控制面线程以及各个数据面线程绑定到不同的CPU核，节省反复调度的性能消耗。其工作模式类似于一个CPU核绑定一个死循环线程，专心处理各自的业务。比如两个网卡eth0和eth1都收包，可以让cpu0专心处理eth0，cpu1专心处理eth1，没必要cpu0一下处理eth0，一下又处理eth1，这样就提高了多核CPU的使用效率。
所以，这样看来，DPDK并不高深，用到的东西也都是Linux本身提供的特性，还有额外的内存池、环形缓存等，虽然封装得很好，但都是比较常用经常接触的技术。
㈥ linux 下怎么优化mysql占用内存
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
㈦ 如何设置myeclipise 的最优内存
处理器通过地址访问内存单元，程序中用到的基址加偏移地址是线性地址，需要通过MMU将虚拟地址映射成物理地址。这给分配和释放内存带来方便:1)物理地址不连续的空间可以映射为逻辑上连续的虚拟地址。2)进程可以获得比实际内存大的"空间"，虚拟内存使得进程在这种情况下仍可正常运行。linux内核为驱动程序提供了一致的内存管理接口，因此不用考虑不同体系结构如何管理内存的。在linux内核中分配内存用kmalloc和kfree。kmalloc分配时可以被阻塞，且不对所获得的区域清零。它分配的区域在物理内存中也是连续的。原型:#includevoid*kmalloc(size_tsize,intflags);//参数为分配大小及分配标志flags参数:GFP_KERNEL:内核内存通用分配方法，表示内存分配是由运行在内核空间的进程执行的。可休眠，所以使用GFP_KERNEL分配内存的函数必须是可重入的。GFP_ATOMIC:用于在中断处理例程或者运行在进程上下文之外的代码中分配内存，不可休眠。内核通常会为原子性的分配预留一些空闲页面。所有标志定义在中。size参数:内核是基于页技术分配内存，以最佳的利用系统的RAM。linux处理内存分配的方法是:创建一系列的内存对象池，每个池的内存大小事固定的，处理分配请求时，就直接在包含足够大的内存块中传递一个整款给请求者。内核只能分配一些预定义的固定大小的字节数组。kmalloc能处理的的最小内存块是32或者64，不大于128KB。内存区段:linux内核把内存分为3个区段:可用于DMA的内存，常规内存以及高端内存。kmalloc不能分配高端内存。内存区段在mm/page_alloc.c中实现。区段的初始化在对应的arch树下的mm/init.c中。后备高速缓存(lookasidecache)内核中普通对象进行初始化所需的时间超过了对其进行分配和释放所需的时间，因此不应该将内存释放回一个全局的内存池，而是将内存保持为针对特定目而初始化的状态。例如，如果内存被分配给了一个互斥锁，那么只需在为互斥锁首次分配内存时执行一次互斥锁初始化函数（mutex_init）即可。后续的内存分配不需要执行这个初始化函数，因为从上次释放和调用析构之后，它已经处于所需的状态中了。linux2.6中USB和SCSI驱动程序使用了这种高速缓存，是为一些反复使用的块增加某些特殊的内存池。后背高速缓存管理也叫slab分配器，相关函数和类型在中申明。slab分配器实现高速缓存具有kmem_cache_t类型。kmem_cache_t*kmem_cache_create(constchar*name,size_tsize,size_talign,unsignedlongflags;void(*constructor)(void*,kmem_cache_t*,unsignedlong),void(*destructor)(void*,kmem_cache_t*,unsignedlong));用于创建一个新的高速缓存对象。constructor用于初始化新分配的对象，destructor用于清除对象。一旦某个对象的高速缓存被创建以后，就可以调用kmem_cache_alloc从中分配内存对象。void*kmem_cache_alloc(kmem_cache_t*cache,intflags);释放内存对象使用kmem_cache_freevoidkmem_cache_free(kmem_cache_t*cache,constvoid*obj);在内存空间都被释放后，模块被卸载前，驱动程序应当释放他的高速缓存。intkmem_cache_destory(kmem_cache_t*cache);要检查其返回状态，如果失败，表明莫块中发生了内存泄露。基于slab的高速缓存scullckmem_cache_t*scullc_cache;scullc_cache=kmem_cache_creat("scullc",scullc_quantum,0,SLAB_HWCACHE_ALIGN,NULL,NULL);if(!scullc_cache){scullc_cleanup();return-ENOMEM;}if(!dpte->data[s_pos]){dptr->data[s_pos]=kmem_cache_alloc(scullc_cache,GFP_KERNEL);if(!dptr->data[s_pos])gotonomem;memset(dptr->data[s_pos],0,scullc_quantum);}for(i=0;idata[i])kmem_cache_free(scullc_cache,dptr->data[i]);}if(scullc_cache)kmem_cache_destory(scullc_cache);内存池:内核中有些地方的内存分配是不允许失败的，为确保能分配成功，内核建立一种称为内存池的抽象，他试图始终保持空闲状态，以便紧急情况使用。mempool_t*mempool_creat(intmin_nr,mempool_alloc_t*alloc_fn,//对象分分配mempool_alloc_slabmempool_free_t*free_fn,//释放mempool_free_slabvoid*pool_data);可以用如下代码来构造内存池cache=kmem_cache_creat();//创建一个高速缓存pool=mempool_creat(MY_POOL_MINIMUM,mempool_alloc_slab,mempool_free_slab,cache);//建立内存池对象void*mempool_alloc(mempool_t*poll,intgfp_mask);//分配对象void*mempool_free(void*element,mempool_t*poll);//释放对象voidmempool_destroy(mempool_t*poll);//销毁内存池注意:mempool会分配一些内存块，空闲且不会被用到，造成内存的大量浪费。所以一般情况不要用内存池。
㈧ 如何在linux下实现event事件机制
内部使用select、epoll、kqueue等系统调用管理事件机制只提供了简单的网络API的封装,线程池,内存池,递归辅助功能函数、日志、libevent框架、对系 统I/O如何在linux下实现event事件机制
㈨ 怎样设计一个内存池，减少内存碎片
一般工程里不推荐你写，因为你费力写一个出来99%可能性没有内置的好，且内存出bug难调试
一定要设计的话，你也可以当个玩具写写玩玩：
1. 实现教科书上的内存分配器：
做一个链表指向空闲内存，分配就是取出一块来，改写链表，返回，释放就是放回到链表里面，并做好归并。注意做好标记和保护，避免二次释放，还可以花点力气在如何查找最适合大小的内存快的搜索上，减少内存碎片，有空你了还可以把链表换成伙伴算法，写着玩嘛。
2. 实现固定内存分配器：
即实现一个 FreeList，每个 FreeList 用于分配固定大小的内存块，比如用于分配 32字节对象的固定内存分配器，之类的。每个固定内存分配器里面有两个链表，OpenList 用于存储未分配的空闲对象，CloseList用于存储已分配的内存对象，那么所谓的分配就是从 OpenList 中取出一个对象放到 CloseList 里并且返回给用户，释放又是从 CloseList 移回到 OpenList。分配时如果不够，那么就需要增长 OpenList：申请一个大一点的内存块，切割成比如 64 个相同大小的对象添加到 OpenList中。这个固定内存分配器回收的时候，统一把先前向系统申请的内存块全部还给系统。
3. 实现 FreeList 池：
在你实现了 FreeList的基础上，按照不同对象大小（8字节，16字节，32，64，128，256，512，1K。。。64K），构造十多个固定内存分配器，分配内存时根据内存大小查表，决定到底由哪个分配器负责，分配后要在头部的 header 处（ptr[-sizeof(char*)]处）写上 cookie，表示又哪个分配器分配的，这样释放时候你才能正确归还。如果大于64K，则直接用系统的 malloc作为分配，如此以浪费内存为代价你得到了一个分配时间近似O（1）的内存分配器，差不多实现了一个 memcached 的 slab 内存管理器了，但是先别得意。此 slab 非彼 slab（sunos/solaris/linux kernel 的 slab）。这说白了还是一个弱智的 freelist 无法归还内存给操作系统，某个 FreeList 如果高峰期占用了大量内存即使后面不用，也无法支援到其他内存不够的 FreeList，所以我们做的这个和 memcached 类似的分配器其实是比较残缺的，你还需要往下继续优化。
4. 实现正统的 slab （非memcached的伪 slab）代替 FreeList：
这时候你需要阅读一下论文了，现代内存分配技术的基础，如何管理 slab 上的对象，如何进行地址管理，如何管理不同 slab 的生命周期，如何将内存回收给系统。然后开始实现一个类似的东西，文章上传统的 slab 的各种基础概念虽然今天没有改变，但是所用到的数据结构和控制方法其实已经有很多更好的方法了，你可以边实现边思考下，实在不行还可以参考 kernel 源码嘛。但是有很多事情应用程序做不了，有很多实现你是不能照搬的，比如页面提供器，可以提供连续线性地址的页面，再比如说 kernel 本身记录着每个页面对应的 slab，你查找 slab 时，系统其实是根据线性地址移位得到页面编号，然后查表得到的，而你应用程序不可能这么干，你还得做一些额外的体系来解决这些问题，还需要写一些额外的 cookie 来做标记。做好内存收缩工作，内存不够时先收缩所有分配器的 slab，再尝试重新分配。再做好内存回收工作，多余的内存，一段时间不使用可以还给操作系统。
5. 实现混合分配策略：
你实现了上面很多常见的算法后，该具体阅读各种内存分配器的代码了，这些都是经过实践检验的，比如 libc 的内存分配器，或者参考有自带内存管理的各种开源项目，比如 python 源码，做点实验对比他们的优劣，然后根据分配对象的大小采用不同的分配策略，区别对待各种情况。试验的差不多了就得引入多线程支持了，将你的锁改小。注意很多系统层的线程安全策略你是没法弄的，比如操作系统可以关中断，短时间内禁止本cpu发生任务切换，这点应用程序就很麻烦了，还得用更小的锁来代替。当锁已经小到不能再小，也可以选择引入 STM 来代替各种链表的锁。
6. 实现 Per-CPU Cache：
现代内存分配器，在多核下的一个重要优化就是给多核增加 cache，为了进一步避免多线程锁竞争，需要引入 Per-CPU Cache 了。分配内存先找到对应线程所在的cpu，从该cpu上对应的 cache 里分配，cache 不够了就一次性从你底层的内存分配器里多分配几个对象进来填充 cache，释放时也是先放回 cache，cache里面如果对象太多，就做一次收缩，把内存换个底层分配器，让其他 cpu 的cache有机会利用。这样针对很多短生命周期的频繁的分配、释放，其实都是在 cache 里完成的，没有锁竞争，同时cache分配逻辑简单，速度更快。操作系统里面的代码经常是直接读取当前的cpu是哪个，而应用层实现你可以用 thread local storage 来代替，目前这些东西在 crt的 malloc 里还暂时支持不到位（不排除未来版本会增加），可以更多参考 tc/jemalloc。
7. 实现地址着色:
现代内存分配器必须多考虑总线压力，在很多机型上，如果内存访问集中在某条 cache line相同的偏移上，会给总线带来额外的负担和压力。比如你经常要分配一个 FILE 对象，而每个 FILE对象使用时会比较集中的访问 int FILE::flag; 这个成员变量，如果你的页面提供器提供的页面地址是按照 4K对齐的，那么很可能多个 FILE对象的 flag 成员所处的 cache line 偏移地址是相同的，大量访问这些相同的偏移地址会给总线带来很大负担，这时候你需要给每个对象额外增加一些偏移，让他们能够均匀的分布在线性地址对应的cache line 偏移上，消减总线冲突的开销。
8. 优化缓存竞争：
多核时代，很多单核时代的代码都需要针对性的优化改写，最基本的一条就是 cache 竞争，这是比前面锁竞争更恶劣的情况：如果两个cpu同时访问相同的 cache-line 或者物理页面，那么 cpu 之间为了保证内存一致性会做很多的通信工作，比如那个cpu0需要用到这段内存，发现cpu1也在用，那么需要通知cpu1，将cpu1 L1-L2缓存里面的数据写回该物理内存，并且释放控制权，这时cpu0取得了控制权才能继续操作，期间cpu0-cpu1之间的通信协议是比较复杂的，代价也是比较大的，cache竞争比锁竞争恶劣不少。为了避免 cache 竞争，需要比先前Per-CPU cache 更彻底的 Per-CPU Page 机制来解决，直接让不同的cpu使用不同的页面进行二次分配，彻底避免 cache 竞争。具体应用层的做法也是利用线性地址来判断所属页面（因为物理页面映射到进程地址也是4k对齐的），同时继续使用 thread local storage 或者用系统提供的 api 读取当前属于哪个 cpu 来实现。为了避免核太多每个核占据大量的页面带来的不必要的浪费，你可以参考下 Linux 最新的 slub 内存分配算法，但是 slub 也有未尽之处，好几个 linux 发行版在实践中发现 slub 还是存在一些问题的（非bug，而是机制），所以大部分发行版默认都是关闭 slub 的，虽然，你还是可以借鉴测试一下。
9. 调试和折腾：
继续参考各种现代内存分配器，取长补短，然后给你的分配器添加一些便于调试的机制，方便诊断各种问题。在你借鉴了很多开源项目，自己也做了一些所谓的优化，折腾了那么久以后，你或许以为你的分配器可以同各种开源分配器一战了，测试效果好像也挺好的，先别急，继续观察内存利用率，向操作系统申请/归还内存的频率等一系列容易被人忽视的指标是否相同。同时更换你的测试用例，看看更多的情况下，是否结果还和先前一样？这些都差不多的时候，你发现没有个一两年的大规模持续使用，你很难发现一些潜在的隐患和bug，可能你觉得没问题的代码，跑了两年后都会继续报bug，这很正常，多点耐心，兴许第三年以后就比较稳定了呢？
㈩ swig3.0.8 linux怎么安装
你找个工具将这个接口API，自动转换成python版本的就可以了。好象是SWIG和Boost。 这两个以前看过，偶尔还试过几次。之所以建议你用自动工具，就是因为python对于C 扩展麻烦些，对于C语言接口可以使用ctypes和cython简单解决。不过C 如果用这些方法有时候被很麻烦。
boost在linux里会经常用到，在windows下也可以使用。SWIG在一般的教程里都会提及到。SIP也是最近出名的。
下面是一些参考资料，搜索来的。
=== 使用工具进行扩展 ===
虽然扩展过程并不复杂，但也可以使用许多已知的工具简化扩展过程。
(1) SWIG
由David Beazley创建，是一个自动的扩展构造工具。它读入注释的C/C 头文件，为python、tcl、perl等多种脚本语言产生wrap代码。SWIG可以包装大量C 特性到Python的扩展模块中。
评价：swig简单，可以支持多种脚本文件，但支持的c 特性不完备。
(2) SIP
由Phil Thompson创建，是一个C 模块构造器，专门为C 的类创造wrapper。它曾经被用于创建PyQt和PyKDE扩展模块，因此比较出名。
评价：支持C 特征很齐全，但比较复杂。
(3) bgen
该工具被包含在标准Python发布包中的模块构建工具集里，由Jack Jansen维护。它用于产生在Macintosh版本可用的Python扩展模块。
(4) pyfort
由Paul bois创建，用来产生Fortran语言生成的扩展模块。
(5) cxx
也由Paul Dubois创建，甫俯颠谎郯荷奠捅订拉是一个库，为Python的C 扩展提供了友好的API。Cxx允许将许多python对象（如list和tuple）使用到STL的运算中。库也提供了C 异常处理到python异常处理的转化。
(6) WrapPy
由Greg Couch创建，通过读入C 头文件来产生扩展模块。
(7) Boost Python Library
由David Abrahams创建。该库提供了更多与众不同的C wrap到python扩展中，而只需要对要扩展的C 类写很少的附加信息。
评价：Boost为C 提供了许多实用的库，如Regex（正则表达式库）、Graph（图组件和算法）、concept check（检查泛型编程中的concept）、Thread（可移植的C 多线程库）、Python（把C 类和函数映射到Python之中）、Pool（内存池管理）等等。
Boost总体来说是实用价值很高，质量很高的库。并且强调对跨平台的支持。但是Boost中也有很多是实验性质的东西，在实际的开发中实用需要谨慎。
boost.python支持的c 特性较多，但是比较复杂。