Chinaunix

标题: 【专家坐镇，16本图书大礼】熟知内核及应用态，打通Linux编程任督二脉（获奖名单已... [打印本页]

作者: Godbach 时间: 2016-07-04 14:47
标题: 【专家坐镇，16本图书大礼】熟知内核及应用态，打通Linux编程任督二脉（获奖名单已...
在本次图书出版活动中，获得《Linux环境编程：从应用到内核》的网友有：

_nosay
shenlanyouyu
niao5929
toe1121
philarlala
shijiang1130
txchxl
henrystark
itpub路在何方
wait_rabbit
ynchnluiti
cxsvip

请以上获奖者在2016年9月25日前将姓名，公司，职务，行业，电话，邮箱，QQ，地址，所选纪念品，站内短信发送给王楠w_n以便及时给您快递奖品。

发不了站短的，请在原帖下方跟帖留言。

至于QQ现因两个编辑轮番值班登陆，可能会有遗漏的情况，有任何问题请尽量在原帖下方跟帖留言或在站务版块反馈，谢谢！

注：因特殊原因，每次活动的获奖者我都会通知各位，如果大家在截止日期之前还未联系到管理员，那么本次活动的得奖资格将被取消，所以请大家及时的与管理员取得联系，谢谢合作！

背景介绍：

21 世纪最需要什么样的工程师？全栈工程师。你要调的通 kernel，写的出应用，玩的转 PHP，搞的定UED，……。而 kernel 以及底层应用，则是 Linux 系统编程以及运维中最为基础的环节。
本次活动将基于 kernel 与用户态应用的结合展开讨论。

特邀嘉宾：

高峰（GFree_Wind）
李彬（Bean_lee）

两位嘉宾是《Linux环境编程：从应用到内核》的作者，有着丰富的 Linux 内核及用户态编程经验。

讨论话题（包括但不限于）

1. 曾经调试用户态的问题，结果深入到了 kernel，甚至发现了 kernel 的 bug
2. 更换了 kernel 版本，解决了用户态的棘手问题
3. 曾经有过从应用层直接杀到内核态的经历
4. 曾经通过 kernel 的一些功能或者编写 kernel 代码，提升用户态的性能或者稳定性

欢迎任选一个到多个话题畅所欲言。

活动时间：

2016.7.4--2016.8.20

活动奖励：

活动结束后，我们将会选取16个优质回复，各送《Linux环境编程：从应用到内核》图书一本。

奖品中有 10 本图书是由《Linux环境编程：从应用到内核》作者之一高峰现就职的全讯汇聚网络科技（北京）有限公司赞助。
感谢全讯汇聚网络科技（北京）有限公司对本次活动的大力支持！

作者：高峰李彬
丛书名： Linux/Unix技术丛书
出版社：机械工业出版社
ISBN：9787111536109
上架时间：2016-6-14
出版日期：2016 年6月
开本：16开
页码：596
版次：1-1
所属分类：计算机 > 操作系统 > Linux

购买链接：http://item.jd.com/11962820.html

内容简介：本书是Linux技术专家高峰和李彬的合力之作，是两个人多年开发经验的总结和分享，也是市场上唯一一本将Linux应用态与内核态相结合的技术图书，选择这种写作方式是为了向APUE的作者致敬。本书涵盖了APUE中大部分章节的内容，并针对Linux环境，根据作者多年经验，详细解析了Linux常用接口的使用方法和陷阱。为了让读者更清楚地理解接口的工作原理，对于绝大部分接口，作者都深入仁库或内核源码进行全面分析。希望本书可以帮助读者打通Linux环境的应用和内核两条脉络，使两条线融会贯通，进一步提高开发水平。

试读样章：

Linux环境编程：从应用到内核.pdf (2.52 MB, 下载次数: 352)

作者: daili0703 时间: 2016-07-04 14:52

作者: GFree_Wind 时间: 2016-07-04 21:27
业界把Linux程序员分为两个大类，一类是内核层开发，另一类是应用层开发——后者又被细分为服务器端开发，应用程序开发等等。在我看来，对于一名优秀的Linux程序员，这些边界都应该是模糊的，无所谓内核层还是应用层，无所谓服务端开发，还是写个客户端，都应该信手拈来，不会有不可预期的困难。这一切就需要有比较牢固的基本功（数据结构和算法），对Linux环境及其运行机制有比较深刻的理解。前者不必多说，相关的书籍也很多。对于后者，如果只是光看书是不够的，必须要亲自体验，亲自阅读内核源码。

　　我自己在阅读了一定内核源码之后，真正地理解了Linux大神这句话“Read the fucking codes”。因为只有阅读了内核源码，才能真正理解Linux内核的原理和运行机制，而此时，我也发现了Stevens大神著作的一个局限——APUE和UNP毕竟是针对Unix环境而写的，Linux虽然大部分与Unix兼容，但是在很多行为上与Unix还是完全不同的。这就导致了书中的一些内容与Linux环境中的实际效果是矛盾的。

作者: _nosay 时间: 2016-07-05 07:23
从网关的镜像数据，解析http,ftp等上层协议，用户态代码一再优化，还是达不到用户要求，后来通过修改网卡驱动实现零拷贝，让性能又改善一大步，我对计算机"内部"充满好奇，但《Linux内核源代码情景分析》放在床头当了4年鼠标垫，才真正变成一本书

还有就是后来用nids的时候，报文总是不能进回调函数，后来发现网卡上接发包中断数为0，也是通过修改网卡驱动搞好的。
现在所在公司做应用开发，遇到问题就靠经验和各种试，根本没有明确的解决思路，很多问题最终不了了之，有些人会用一些小聪明的做法，先掩盖过当前这个bug，忽悠过领导，然后创造更多的bug，反正这些bug到时候还不知道分给谁呢，而且这貌似已经是一种"默契"，正好可以多加班，养家糊口，而我不喜欢这样。

作者: Godbach 时间: 2016-07-05 08:39
回复 3# GFree_Wind
感谢高兄分享！

作者: Godbach 时间: 2016-07-05 08:40
回复 4# _nosay
感谢分享。

果然是深入内核之后，解决应用层的问题会更加得心应手。

作者: chenyx 时间: 2016-07-05 11:02
内核开发,太高端,友情支持下

作者: shenlanyouyu 时间: 2016-07-05 11:03
回复 3# GFree_Wind

这本书刚在china-pub放出新书通告时，就关注了，没有想到作者竟然是CU的GFree_Wind。作为一个内核的爱好者，市面上的kernel书籍都收了，这本书一定不能错过，从应用编程到内核分析，看完之后一定会收获颇多。
要提升，还是要多看源码，学习好的设计思想，然后应用。

作者: shenlanyouyu 时间: 2016-07-05 11:04
回复 1# Godbach

活动木有样章，希望可以有样章啊。

作者: GFree_Wind 时间: 2016-07-05 12:00
回复 4# _nosay

当年我也是做应用层开发，总是好奇其内部的机制。遇到问题时，深入内核就知道原因了，同时还提高了自己对系统的理解。

作者: GFree_Wind 时间: 2016-07-05 12:00
回复 8# shenlanyouyu

多谢关注

作者: 王楠w_n 时间: 2016-07-05 12:57
样章下午更新出来

回复 9# shenlanyouyu

作者: _nosay 时间: 2016-07-05 13:00
回复 10# GFree_Wind

大牛说的话我都听

作者: Godbach 时间: 2016-07-05 13:33
回复 7# chenyx

多谢 chenyx 支持，更欢迎分享。

作者: Godbach 时间: 2016-07-05 13:34
回复 9# shenlanyouyu

样张正在问出版社要。稍等一下应该就会有的。

作者: Godbach 时间: 2016-07-05 13:35
回复 8# shenlanyouyu

是的，归根结底，还是要 Read the f**king code.

作者: hellioncu 时间: 2016-07-05 14:29
我早先是做windows开发的，从客户端到服务端，后来服务端跨平台到了Unix／Linux，重点放在架构设计上，很少涉及Linux内核，最多调整些内核参数。有谁能多举点例子，让我增加点研究内核的动力

作者: 文峰聊书斋 时间: 2016-07-05 18:04
学应用，会总搞不清进程和线程区别。看内核，才发现线程就是进程，不过是轻量级的。VM域指向同一个地方而已。能看懂内核，做应用真心很顺手。

作者: GFree_Wind 时间: 2016-07-05 21:41
回复 17# hellioncu

我举个例子吧。
比如你知道在Linux下，如何可以bind一个非本机地址？

APUE上说只能bind本机地址，man手册则一点没有提。
而从源码上我们可以得知，利用sysctl_ip_nonlocal_bind开关，就可以bind非本机地址。

作者: Bean_lee 时间: 2016-07-05 23:15

我觉得自己是一个典型的C程序员，很没有安全感同时又很八卦，在学习Linux编程的时候，我经常会问自己一些比较牛角尖的问题：

1 如果多个信号同时到达，内核到底先递送那个信号给进程？
2 为什么很多人诟病传统的信号（比如Rebort Love Linux系统编程中提到的），传统信号到底哪里不好，后面出现的实时信号又做了哪些改进？
3 多线程编程中，互斥量是不是公平的，先到的互斥量加锁请求是不是一定会先获得互斥量？
4 POSIX信号量和System V信号量，谁的性能好，为什么，以及两者之间到底存在哪些区别？
5 对于读写锁，如果同时存在读锁请求和写锁请求，哪个请求先得到满足？
6 UNIX系统编程一书，很多系统调用，为什么一言不合就判断errno == EINTR？
7 为什么多线程程序不建议调用fork，我调用fork到底会怎样？
8 mmap映射文件，如果修改了文件的内容，还没来得及msync和munmap，对文件的修改是否能持久化。
9 多线程的进程收到了信号，到底哪个线程负责处理信号？

如果我调用一个函数，我不知道里面发生了什么事情，我就会觉得很慌，

有句话是这么说的：

你以为你以为的就是你以为的。

学习阶段，要解决这些困惑，仅仅是RTFM（Read the fucking manual）并不够，还需要深入glibc源码，深入到内核源码，甚至要写一些测试的代码，验证你的理解到底对不对。当你调用某个函数时，你能初步地了解内核做了哪些事情，会带来哪些影响，这种感觉还是很好的。

Linux内核博大精深，自己对内核的理解确实有限，尤其是CU社区卧虎藏龙，Linux领域大牛甚多，我自己有很多东西都是跟着CU的大牛学的，不敢多说，做小板凳看小伙伴们发言。

作者: Godbach 时间: 2016-07-06 00:34
回复 18# cxsvip

感谢分享！

作者: Godbach 时间: 2016-07-06 00:35
回复 21# Bean_lee

所谓学而不思则罔，要勤学勤思考。

作者: niao5929 时间: 2016-07-06 08:16

微软的系统有通用性，但其稳定性和开放度远不是能评论的;IBM的AIX有非常好的稳定性，但其失去了通用性；苹果的OS通用性就更不用说了。如果从通用性、稳定性、开放性三个维度去测评，无疑自由软件Gnu/Linux是最棒的！！！

作者: hellioncu 时间: 2016-07-06 08:22

GFree_Wind 发表于 2016-07-05 21:41
回复 17# hellioncu

我举个例子吧。

麻烦再解释下这样做的实际意义吧

作者: 流氓无产者 时间: 2016-07-06 09:45

hellioncu 发表于 2016-07-05 14:29
我早先是做windows开发的，从客户端到服务端，后来服务端跨平台到了Unix／Linux，重点放在架构设计上，很少 ...

你们不是有个kernel team?
kernel.taobao.org
你问他们啊

作者: 文峰聊书斋 时间: 2016-07-06 10:07
厉害。元老级。

作者: Godbach 时间: 2016-07-06 13:37
回复 24# niao5929

只有开放了，才更有利于大家的参与。

作者: GFree_Wind 时间: 2016-07-06 13:53
回复 25# hellioncu

透明代理，HA，等等

作者: GFree_Wind 时间: 2016-07-06 13:54
回复 29# GFree_Wind
当然，没有free bind选项，也可以通过其它方法实现。

但是有了这个，更方便

作者: forgaoqiang 时间: 2016-07-06 14:14
突然间感觉蹦出来好多系统程序员

看源码了解本质这个无论在内核还是应用层都是适用的

作者: Fl_wolf 时间: 2016-07-06 15:19
表示内核没有深入研究过，默默学习中。

作者: Godbach 时间: 2016-07-06 16:00
回复 32# Fl_wolf

平时工作主要侧重应用层？

作者: niao5929 时间: 2016-07-06 20:41
o也是应用哦。不过看过LINUX内核代码实现那本书。云里雾里的。哈哈回复 33# Godbach

作者: GFree_Wind 时间: 2016-07-06 22:01
回复 34# niao5929

哪本？《Linux内核设计与实现》吗？

作者: GFree_Wind 时间: 2016-07-06 22:09
现在CU论坛越来越冷清了。。。。

当年在CU上没少学东西。CSDN倒是热闹，一方面是过度商业化，另一方面csdn又比较水

作者: Godbach 时间: 2016-07-07 10:45
回复 9# shenlanyouyu

样章有了

作者: dreamice 时间: 2016-07-07 10:58
回复 1# Godbach

支持活动！
曾经对内核是情有独钟，然后慢慢工作转到应用上来，内核版本发展太快了，现在很多业务工作涉及到内核的也越来越少。

作者: shenlanyouyu 时间: 2016-07-07 11:32
回复 37# Godbach
昨天晚上已经下载，看完后参与。

作者: Godbach 时间: 2016-07-07 11:34
回复 39# shenlanyouyu

期待你的分享。

作者: yanggq 时间: 2016-07-07 13:18
果然很牛，学习一下看看。

作者: Godbach 时间: 2016-07-07 13:22
回复 38# dreamice

多谢江总支持。

作者: niao5929 时间: 2016-07-07 15:41
解希仁的那套两厚本的书回复 35# GFree_Wind

作者: niao5929 时间: 2016-07-07 15:44
CSDN感觉像个骗子+，把技术交流的风气带坏了！！！回复 36# GFree_Wind

作者: shenlanyouyu 时间: 2016-07-07 15:45
本帖最后由 shenlanyouyu 于 2016-07-07 15:47 编辑

回复 40# Godbach

果断支持！

读了样章，收获挺大。作者分析了常见的文件操作相关的系统调用，从系统调用的使用，系统调用的实现方法，逐步分析到内核功能的实现。并根据自己的经验，分析了调用系统调用需要注意的问题，防止踩坑。建议：如果在基础知识那章，添加程序链接的基础知识，用图形来说明编译后的obj和C标准库之间的关系，动态链接的过程，会比较系统，容易理解。

曾经有过从应用层直接杀到内核态的经历，在父进程中，打开一个文件，然后fork出一个子进程，在进程读写文件，导致父进程的文件读写位置出现问题，trace系统调用fork的实现，分析fork过程中，子进程继承了父进程打开的文件描述符，增加了进程文件描述符表指向的file的引用计数。2.4节fdopen与 fileno，我曾经也研究过FILE和fd的关系。

研究select多路复用机制的内核实现，了解select的内核的实现，才能明白在文件数量上升时select效率底下的原因，以及为什么epoll更高效。每次调用select，都需要把fd集合从用户态拷贝到内核态，同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd数量上升时也很大。找到root’ cause，才能针对性设计新的系统调用。其次，掌握了select的内部实现，对编写driver的poll函数有极大的帮助。

还有把Android Binder driver搬到PC上调试，最初是直接编译module方式，结果每次编译成功，insmod失败。can_nice, put_files_struct…..没有定义，trace内核发现，这些API都没有EXPORT出来，binder只能built-in到内核中，然后下载最新的内核，config编译，然后内核安装到Ubuntu，添加grub启动项，重启选择进入搞定。ls /dev/binder找到，然后把android的service manger等等，搞过来调试。

作者: Godbach 时间: 2016-07-07 21:56
回复 45# shenlanyouyu

感谢分享！

作者: GFree_Wind 时间: 2016-07-07 22:21
回复 44# niao5929

有点这种感觉。同时CSDN中微软的力量太强大了。。。。

作者: GFree_Wind 时间: 2016-07-07 22:23
回复 43# niao5929

利用 “解希仁 linux”，搜索不到啊

作者: GFree_Wind 时间: 2016-07-07 22:24
回复 37# Godbach

我也下载看看

作者: GFree_Wind 时间: 2016-07-07 22:41
回复 45# shenlanyouyu

建议：如果在基础知识那章，添加程序链接的基础知识，用图形来说明编译后的obj和C标准库之间的关系，动态链接的过程，会比较系统，容易理解。
—— 这个确实可以扩展一下。不过我的缺点是不善于画图，所以画图的事情，我能省就省了。。。

另外，还有一个原因，《程序员的自我修养——链接、装载和库》已经把这个过程写得比较详细了。第一次写书，我不太想写一些别人写过的，或者大家都知道的东西。所以在本书中，我负责的章节中，基础的东西，我要么不写，要么是一笔带过。

作者: Assassin_Duv 时间: 2016-07-08 08:46
感谢分享，支持一下，已下单啦。希望自己能从前辈们的经验中收获到许多非常有价值的东西。向前辈们致敬。

作者: Godbach 时间: 2016-07-08 09:25
回复 51# Assassin_Duv

也欢迎做分享啊。

作者: GFree_Wind 时间: 2016-07-08 10:20
回复 51# Assassin_Duv

感谢支持~~

作者: toe1121 时间: 2016-07-08 18:11
2014年做的项目，当时对性能要求很苛刻，为了减少用户态数据写到磁盘的过程提高性能，写了一个用户态和内核态的零拷贝功能，性能杠杠的。还借鉴了intel的一个无锁环形队列，稳定性在特定应用上还是很不错的。
如果内核能直接提供这种零拷贝功能会好很多，对性能要求高的环境中，拷贝影响太大。

作者: philarlala 时间: 2016-07-08 18:32
大学期间一直是打酱油的，连课程大作业都是老师见我想哭的样子不好意思为难了，谁知道一工作就让我搞内核，也不知道那时候的老大看中了我那一点，自己是一点自信都没有的，通知上班了，心里还一点底也没有，只能自我安慰说，没事的，既然人家都觉得你可以了，你就去吧。就这样入了内核的门，一开始也是各种状况的，各种折腾。想到什么需求就直接做，试过有一次在软中断中写文件，系统一下子就panic了。当时整个人懵了，这可怎么调试啊！完全超出了当时对调试的认知，也多亏当时的老大指导，搭好了crash+kdump的环境，学会了我的第一个内核调试工具，后面随着接触的多，也会用jprobe，dump_stack ，等函数来辅助调试，还有各种工具，内核自带的kmemleek，systemtap，kgdb，最近也学会了通过串口来进行采集信息，看netpoll的介绍的时候还发现netconsole，在中断不可用的情况下，直接调用中断处理函数来进行处理的。感觉内核好多好玩的东西。估计这也是内核的魅力所在吧，只要你了解了，可以根据自己的需求做各种各样东西，一点限制都没有。

分享一个具体的例子
有个需求是要在内核进行组播，找了个遍，网上的组播的例子，都是在应用层。正郁闷的时候，脑袋瓜子闪了一下，应用层的函数肯定最后都会调用到内核的API的，我只需要找到内核对应的函数，直接调用就好了。关键要处理的是interface加入组播组，让数据包能上ip层，只要上了ip层，一切好办，利用netfilter的框架hook一个函数根据目的ip和端口进行接收处理就ok了

找到内核加入组播组的API ，int ip_mc_join_group(struct sock *sk , struct ip_mreqn *imr)分析一下，sk和imr 这两个参数带下来了什么，就知道在内核层调用的话，需要那些参数，然后参考ip_mc_join_group的实现，实现了一个内核层加入组播组的API，思路大概就是这样，具体实现忘记了，实现过程中可能会有各种小问题，想办法死磕就行，反正到最后搞定了

lol，

其实这里还遗留了一些问题，组播接收的时候是根据组播号和端口(就是数据包的目地ip和目的端口)来确定这个组播包是不是给某个进程，因为我的这个实现都是在三层以及三层以下处理的，而且没有对端口做判断，就是不管应用层有没有用到这个端口，反正如果组播号和端口符合指定的，就会先被三层的这个hook 函数拦下了。如果应用层刚好有个进程端口用一样的，interface加入的组播组也是一样的，就会接收不到数据。

当时老大是觉得反正机器上面跑什么进程都是我们控制的，人为的不要产生冲突就好。我也就懒得去折腾了。

呃，说到最后，感觉乱来了，哈哈，不太会表达

最后还是要感谢一下GFree_Wind的，面试的时候一句话解开了困惑了我很久的问题

作者: baobaofox 时间: 2016-07-08 21:33

希望可以中奖

作者: aku1 时间: 2016-07-09 09:22
必须顶下，后面要补内核这块，我也在看Unix系统编程，单感觉大部分是调用写好的系统函数，所以更底层一点自己理解有限

作者: Godbach 时间: 2016-07-09 13:33
回复 54# toe1121

嗯，针对特定环境定制，提高性能。

作者: Godbach 时间: 2016-07-09 13:37
回复 55# philarlala

感谢分享。简直就是技术成长历程的分享啊！赞。

作者: Godbach 时间: 2016-07-09 13:37
回复 56# baobaofox

得有实际内容的回帖啊。可以分享一下自己的经验。

作者: Godbach 时间: 2016-07-09 13:38
回复 57# aku1

有时间就可以深挖一下，看看 kernel 里怎么实现的。顺着一个 system call 深挖下去，收获肯定不小的。

作者: baobaofox 时间: 2016-07-10 18:32
回复 60# Godbach

开发类的在自学中，还要向大家多学习，我做运维方面的！

作者: Godbach 时间: 2016-07-10 19:10
回复 62# baobaofox

作者: GFree_Wind 时间: 2016-07-10 19:45
回复 54# toe1121

不知道sendfile是否能够满足你的需求

作者: GFree_Wind 时间: 2016-07-10 19:46
回复 55# philarlala

啊。。。咱们面试聊过？

哪句话呢~~~

作者: Godbach 时间: 2016-07-11 20:43
回复 65# GFree_Wind

还勾出来故事了。。。

作者: GFree_Wind 时间: 2016-07-11 21:13
回复 66# Godbach

是啊。还好面试中，我的表现得到这位同志的认可呵。

作者: Godbach 时间: 2016-07-11 22:51
回复 67# GFree_Wind

要信得过自己的实力。

作者: cokeboL 时间: 2016-07-12 17:03
支持。

作者: lxy572535121 时间: 2016-07-12 18:12

GFree_Wind 发表于 2016-07-05 12:00
回复 4# _nosay

当年我也是做应用层开发，总是好奇其内部的机制。遇到问题时，深入内核就知道原因了，同 ...

表示APUE和UNP都看过，目前正在看TCP／IP Illustrated卷一，也想深入学习一下内核，但是不知道这些学完后可以找那方面的工作，求大神指点。
另外APUE看过好多遍，感觉平常不用的话很多东西都会忘掉，怎么才能把看过的都记住？

作者: Godbach 时间: 2016-07-12 20:01
回复 70# lxy572535121

也不用强求自己记住。将来工作用得到了，自然就记住了。

我觉得看书，重要的是，一来你系统的了解了知识，二来将来遇到问题，你知道哪些书介绍过类似问题，可以去查看参考。这样看书的目的就算达到了。

作者: shijiang1130 时间: 2016-07-13 10:05

GFree_Wind 发表于 2016-07-05 21:41
回复 17# hellioncu

我举个例子吧。

1. Some people view the technique of binding to non-local IPs as spoofing, and indeed, it can be used for nefarious purposes, if an attacker controls a machine on the route between a target and a victim.

2. HAProxy 中的 Load Balancing 也需要能綁定至一組nonlocal（非本機）的 IP 位址，代表它不會被分配至本機系統上的裝置。這能讓一個運作中的負載平衡 instance 綁定至一組非本機的的 IP 位址，以進行容錯移轉

作者: Godbach 时间: 2016-07-13 13:26
回复 72# shijiang1130
嗯，你回复的 HAProxy 的那个，场景就是高可用中中主备模式。

作者: txchxl 时间: 2016-07-13 18:02
之前写过skb 模块，主要是处理一些ARP 报文和DNS 报文的，功能很简单，就是有些符合条件的ARP 通过，不符合的扔了或者修改ARP 请求的IP，DNS 也是类似的。模块插在arp.c和ip_input那好像，有点记不清了，开放了proc 文件接口给上层配置。总之是个很简单的功能。后面也只看过一点点802.11的驱动。内核就看过这些。

作者: GFree_Wind 时间: 2016-07-14 08:27
回复 70# lxy572535121

首先APUE和UNP都可以精读三遍以上。
为什么有的东西会记不住呢？
1. 因为很少用；
2. 没有理解后面的实现原理；

只要做到上面两者之一，就不会忘了。我更倾向于第2点，因为谁都不可能不断的使用所有的接口。
只有理解了接口背后的原理，就记住了最本质的东西了。

到了需要的使用，自然可以信手拈来。

作者: Godbach 时间: 2016-07-14 09:18
回复 74# txchxl
你这个需求感觉更行通过 iptable 以及 arptable 就可以实现。自己单独写，是基于什么需求？

作者: txchxl 时间: 2016-07-14 13:32
leader 希望我能接触下底层的知识，然后就没告诉我iptables 可以做，新入职小白刚入行Linux C接触东西又少，就被忽悠去写了。现在知道的netlink 库来做其实更灵活了。

Godbach 发表于 2016-07-14 09:18
回复 74# txchxl
你这个需求感觉更行通过 iptable 以及 arptable 就可以实现。自己单独写，是基于什么需求 ...

作者: Godbach 时间: 2016-07-14 15:27
回复 77# txchxl
愿意让你去练手，肯定更合适了。

不过你这个工作，好像是直接该 kernel。写个 kernel module 是不是都不行？

作者: txchxl 时间: 2016-07-15 08:37
插入内核的模块方便移植和扩展。和直接改内核源码区别不大，功能源码一样，只是要扔出来个钩子

作者: Fl_wolf 时间: 2016-07-15 16:17
回复 33# Godbach

是的基本上都是在应用层

作者: Fl_wolf 时间: 2016-07-15 16:26
回复 33# Godbach

希望能中奖就有理由给自己了解下内核了哈哈

作者: Godbach 时间: 2016-07-15 23:04
回复 79# txchxl
你用的是 kernel 现成的钩子？

作者: Godbach 时间: 2016-07-15 23:05
回复 81# Fl_wolf
应用层也可以分享一些经验嘛。

作者: 伤心的王子7 时间: 2016-07-18 13:36

作者: henrystark 时间: 2016-07-19 15:20
分享两个：
1.打印log导致性能低的问题。
当时有哥们改开源程序，发现用远程ssh调试性能高，打印到本地性能低。后来历经曲折发现原来是打印log，写的目的位置有所差异。远程调试走网络，本地调试打到了console，而写到console，要经历一系列系统调用，当时翻查了write等的实现。这件事得到的经验是：再小的细节，背后可能隐藏着庞大的机制，不可不谨慎。
2.更换内核版本影响并发连接数。
测试上万的并发连接数在不同内核版本的影响。发现有些发行版不支持，比如Centos，有些完全没问题，比如Ubuntu，具体的发行版本号已经不记得了。当时挺费解的，不过找到可用的内核版本以后就没管了。有兴趣有精力的可以尝试下。

作者: Godbach 时间: 2016-07-19 15:30
回复 85# henrystark

感谢分享。看来跳过的坑，都是记忆犹新。

作者: txchxl 时间: 2016-07-19 21:45
不是，其实是模仿钩子的一种写法，也是用函数指针实现的。记不清怎么写的了，只记得位置和一些操作原理了。

Godbach 发表于 2016-07-15 23:04
回复 79# txchxl
你用的是 kernel 现成的钩子？

作者: GFree_Wind 时间: 2016-07-19 22:17
回复 85# henrystark

就我自己的测试，CentOS7服务端的RPS比CentOS6.5大约提高1倍。

作者: Godbach 时间: 2016-07-19 22:21
回复 88# GFree_Wind

是 kernel 或者 driver 的原因？

作者: Godbach 时间: 2016-07-19 22:22
回复 87# txchxl

函数指针也算钩子吧。。

作者: itpub路在何方 时间: 2016-07-20 22:37
我是一个平台运维人员，平时和linux操作系统打交道也很多，也有很多的感悟，对于linux内核态和用户态度我想首先我们要知道了解这两个态和为什么要有这个两个态
以及两个态的切换

内核态: CPU可以访问内存所有数据, 包括外围设备, 例如硬盘, 网卡. CPU也可以将自己从一个程序切换到另一个程序
用户态: 只能受限的访问内存, 且不允许访问外围设备. 占用CPU的能力被剥夺, CPU资源可以被其他程序获取
1，为什么要有用户态和内核态

由于需要限制不同的程序之间的访问能力, 防止他们获取别的程序的内存数据, 或者获取外围设备的数据, 并发送到网络, CPU划分出两个权限等级 -- 用户态和内核态

2，用户态与内核态的切换

所有用户程序都是运行在用户态的, 但是有时候程序确实需要做一些内核态的事情, 例如从硬盘读取数据, 或者从键盘获取输入等. 而唯一可以做这些事情的就是操作系统, 所以此时程序就需要先操作系统请求以程序的名义来执行这些操作.

这时需要一个这样的机制: 用户态程序切换到内核态, 但是不能控制在内核态中执行的指令

这种机制叫系统调用, 在CPU中的实现称之为陷阱指令(Trap Instruction)

他们的工作流程如下:
1.用户态程序将一些数据值放在寄存器中, 或者使用参数创建一个堆栈(stack frame), 以此表明需要操作系统提供的服务.
2.用户态程序执行陷阱指令
3.CPU切换到内核态, 并跳到位于内存指定位置的指令, 这些指令是操作系统的一部分, 他们具有内存保护, 不可被用户态程序访问
4.这些指令称之为陷阱(trap)或者系统调用处理器(system call handler). 他们会读取程序放入内存的数据参数, 并执行程序请求的服务
5.系统调用完成后, 操作系统会重置CPU为用户态并返回系统调用的结果

我想我们大学都学习过计算机组成原理中的批处理，CPU运行机制等原理，其实内核的学习还是很复杂的，很困难的，在我的工作中我是大概分为几个部分学习的。

1，常常看看API，即便读不能一次读懂也要坚持

“比起知道你所用技术的重要性，成为某一个特别领域的专家是不重要的。知道某一个具体API调用一点好处都没有，当你需要他的时候只要查询下就好了。”这句话源于我看到的一篇翻译过来的博客。我想强调的就是，这句话针应用型编程再合适不过，但是内核API就不完全如此。

内核相当复杂，学习起来很不容易，但是当你学习到一定程度，你会发现，如果自己打算写内核代码，到最后要关注的仍然是API接口，只不过这些API绝大部分是跨平台的，满足可移植性。内核黑客基本上已经标准化、文档化了这些接口，你所要做的只是调用而已。当然，在使用的时候，最好对可移植性这一话题在内核中的编码约定烂熟于心，这样才会写出可移植性的代码。就像应用程序一样，可以使用开发商提供的动态库API，或者使用开源API。同样是调用API，不同点在于使用内核API要比使用应用API了解的东西要多出许多。

当你了解了操作系统的实现---这些实现可都是对应用程序的基础性支撑啊---你再去写应用程序的时候，应用程序中用到的多线程，定时器，同步锁机制等等等等，使用共享库API的时候，联系到操作系统，从而把对该API的文档描述同自己所了解到的这些方面在内核中的相应支撑性实现结合起来进行考虑，这会指导你选择使用哪一个API接口，选出效率最高的实现方式。对系统编程颇有了解的话，对应用编程不无益处，甚至可以说是大有好处。

2，设计实现的本质，知道还是理解

操作系统是介于底层硬件和应用软件之间的接口，其各个子系统的实现很大程度上依赖于硬件特性。书上介绍这些子系统的设计和实现的时候，我们读过了，也就知道了，如果再深入考虑一下，为什么整体架构要按照这种方式组织，为什么局部函数要遵循这样的步骤处理，知其然，知其所以然，如果你知道了某个功能的实现是因为芯片就是这么设计的，CPU就是这么做的，那么你的疑问也就基本上到此为止了。再深究，就是芯片架构方面的设计与实现，对于程序员来讲，无论是系统还是应用程序员，足迹探究到这里，已经解决了很多疑问，因为我们的工作性质偏软，而这些东西实在是够硬。

比如，ULK3中讲解的中断和异常的实现，究其根源，那是因为Intel x86系列就是这么设计的，去看看Intel V3手册中相应章节介绍，都可以为ULK3中描述的代码实现方式找到注解。还有时间和定时器管理，同样可以在Intel V3 对APIC的介绍中获取足够的信息，操作系统就是依据这些硬件特性来实现软件方法定义的。

又是那句话，不是理解不理解的问题，而是知道不知道的问题。有时候，知道了，就理解了。在整个学习过程中，知道，理解，知道，理解，知道……，交叉反复。为什么开始和结尾都是知道，而理解只是中间步骤呢？世界上万事万物自有其规律，人类只是发现而已，实践是第一位的，实践就是知道的过程，实践产生经验，经验的总结就是理论，理论源于实践，理论才需要理解。我们学习内核，深入研究，搞来搞去，又回到了芯片上，芯片是物质的，芯片的功用基于自然界中物质本有的物理和电子特性。追本溯源，此之谓也。

3，动手写代码

纸上得来终觉浅，绝知此事要躬行。只看书是绝对不行的，一定要结合课本给出的编程建议自己敲代码。刚开始就以模块形式测试好了，或者自己编译一个开发版本的内核。一台机器的话，使用UML方式调试，内核控制路走到哪一步，单步调试看看程序执行过程，比书上的讲解更直观明了。一定要动手实际操作。

作者: Godbach 时间: 2016-07-20 23:29
回复 91# itpub路在何方

LS 是第一帖啊

欢迎多多分享。

作者: henrystark 时间: 2016-07-21 14:59
回复 88# GFree_Wind

RPS是什么的缩写？并发长连接数？

作者: Godbach 时间: 2016-07-21 15:02
回复 93# henrystark

Receive Packet Steering

作者: Godbach 时间: 2016-07-21 15:04
回复 93# henrystark

实现了从系统层面将 packet 均衡的分不到多个 core 上，而不用依赖于网卡是否支持 RSS。

作者: GFree_Wind 时间: 2016-07-21 21:28
回复 94# Godbach

其实。。。。这里的RPS是。。。。Request Per Second。。。。。

作者: GFree_Wind 时间: 2016-07-21 21:30
回复 95# Godbach

Godbatch说的RPS解释也没错。。。

不过CentOS 6.5后面也加上了RPS补丁。我这里说的RPS是，指每秒钟处理的请求数目。CentOS7要比6.5高出50%以上。

这主要是内核对VFS的优化，之前的锁太多了。

作者: GFree_Wind 时间: 2016-07-21 21:31
回复 96# GFree_Wind

英文缩写太多了，已经不够用了。。。

作者: wait_rabbit 时间: 2016-07-22 00:11
回复 97# GFree_Wind

看到rps这个术语，倒是想起来，以前因为需要，写过一个简单的发包工具，其中一项就是rps，用户态的发包无论如何都压力不够。

后来改在 kernel 里直接收发，也就是调用 tcp_sendmsg 那一套接口，避免了数据从内核态到用户态的拷贝，最后终于达到目标。

作者: Godbach 时间: 2016-07-22 08:53
回复 96# GFree_Wind

哦。这个我们一般称为 QPS

作者: Godbach 时间: 2016-07-22 08:55
回复 99# wait_rabbit

kernel 代码里有个 pktgen。就是用来内核态发包用的。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)