ibmtc小结

不经意间，2006又要离我们远去了，回顾过去一年的工作，感觉有必要写点什么。
这个上半年过得很快，以至于我都没有什么印象，它就过去了。大概回忆一下，这个上半年我一直在做科技创新的前期调查论证工作，科技创新工作也是我这一年工作的重点，至少时间上的安排是这样的。上半年的工作感觉没有太多的内容，至少没有太多看得见摸得着的东西，也许就只有那为数不多的分析报告吧。不过，也算体验了这么一个研究的过程吧，感觉还是有一些收获的。7－8月那一个半月的开发阶段倒是给我留下了深刻的印象，从来没有在这么长的一段时间，集中精力地做那么一件时间，连续不受打扰的，感觉特别棒，而且对于php的使用也达到一个入门的水平，感觉还行。不过那一段的艰苦也是很特别的。科技创新的答辩令大家失望了，我很遗憾，没有得到满意的结果。
科技创新的工作完成后，我参与到Linux Framebuffer小组的工作中来。客观的说，这一段的工作对于我技术上的帮助应该是远远大于科技创新活动的。通过阅读源码，明白了Linux的部分机理，对于使用Linux接近一年的我来说，我觉得是特别必要的。不过阅读代码的工作也是很艰苦的，对此我们都深有体会。
总的说来，我是比较喜欢这后边三个月的工作的，感觉在这三个月里边，技术上的东西接触的比较多，而在上半年，大多数时候都在接触一些概念性的东西，在技术的积累上没有严格要求自己，没有学习到太多的东西，比较可惜，再想到上半年比较空闲的日子，真是在浪费生命啊！
纵观过去一年，我在实验室待的时间比较长，即使不是最长的，也是最长的那么几个之一。不过个人感觉，自己进步的程度没有其他同学高，个人分析，主要是不能潜心研究，总是三心二意，容易被外界干扰。这是我学习过程中遇到的最重要的非技术问题，我想应该想办法了结它了，再也不能看会儿书就灌bbs了。。。

令人郁闷的马哲

明天早上就要马哲考试了，今天被迫准备了一天。说是准备，不就是看书，背书吗？200页的习题集啊，看得我都想吐了，不到一会儿就三心二意、昏昏欲睡了，真是比看代码还痛苦。就这样，还看得不咋的，就有个很粗略的印象，没什么效果。。。不过相信明天的考试还是没有问题的，平时分数就有30分，再加上选择题30分，再随随便便答点问答题，这不就过了。。。
哎，还是想想明天考试完了做什么吧。对了，tty_io.c的代码看得差不多了，该写个报告什么的了，然后做个ppt，星期二给实验室的伙计们讲一下，听听大家的意见。还有接口技术的作业没有做，身份证没有办，这些琐事怎么就这么多呢？

TTY的read从何而来？(beta)

最近几天都在看tty_io.c，基本上明白了tty的大概组成，也就是tty_driver,tty_ldisc,tty_termios,tty_driver这么几个部分。它们之间的关系也基本清楚，可是一直没有细看tty的write,read等操作从何而来？深入到代码中去，原来是这样的： tty_read调用ld->read,而ld->read是指向read_chan的函数指针，其中read_chan是在N_TTY等不同的链路规则中分别定义的，它实际上也就是对copy_to_user的调用。这里我是这样理解的，对于不用链路规则中的read，它们的本质都是对于buffer的copy_to_user，它们的区别在于什么时候，怎样调用copy_to_user；而buffer中的数据是有设备的具体驱动来维护的，联想到一个链路规则适用于一类设备，那么就是说，这些设备对于buffer的操作都是类似的？我只是猜想，还不能确定；但是它们肯定不会迥异。假如我的猜想正确的话，那么tty是面向用户的对设备的抽象，而tty_ldisc是面向tty的对设备的抽象。除了这个猜想，还有一个不明确的地方，tty_driver干什么，是不是说，tty_driver是对于tty_write这一层次函数的组合，感觉不太必要啊，不应该是这样的吧，恩，明天再明确一下

A tool for call graphs--Egypt

今天继续看tty_io.c的代码，代码中定义了很多操作buffer的函数，它们之间有相互调用，看着真混乱。于是，就想找一个能生成函数调用图的软件，尝试了doxygen，发现只能生成C++的类关系图，对于C没作用。然后，找到这个，感觉功能比较简单，好上手，先试试。。。

Egypt is a simple tool for creating call graphs of C programs.

egypt [--omit function,function,...] [--include-external] ... | dotty -
egypt [--omit function,function,...] [--include-external] ... | dot

omit
Omit the given functions from the call graph. Multiple function names may be given separated by commas.
include-external
Include calls to external functions in the call graph. A function is considered external if it is not defined in any of the input files. For example, functions in the standard C library are external. By default, such calls are not shown. Even with this option, only direct calls will be shown; there is no way to show indirect calls to external functions.

Generating the RTL file
make clean
make CFLAGS=-dr
Viewing the CALL GRAPH
egypt foo.c.00.rtl | dotty -

优点和缺点：使用gcc分析source code，使用 dotty生成图像，使用简单；但是必须要生成相应的rtf文件，对于很大的工程，也许相当麻烦。

tty_open和init_dev流程分析

tty_open大致流程：

1. 根据目标设备文件节点inode->i_rdev(device)初始化局部变量 struct tty_driver* driver; int noctty;
2. init_dev函数初始化设备
3. 建立从当前进程到目标设备的连接 flip->private_data=tty; 同时，把指向此设备的file结构挂入tty_struct结构中的队列tty_files file_move(flip,&tty->tty_files);
4. 通过函数指针调用与链路规则相关的open操作
5. 修改当前进程current 和 tty 相关信息

BTW：根据filp->f_op可能有一个retry_open的过程。
init_dev大致流程：

1. check wherher we're reopening an exiting tty
2. 否，alloc_tty_struct() 分配空间
3. 数据结构初始化 initialize_tty_struct(tty);
4. 若想打开pty,则还需要建立o_tty(从设备)，初始化之并建立主从设备之间的相互连接
5. 在建立好设备以后，还需要设置若干termios结构，不太明白怎么回事(termios在某种程度上可以看作ldisc的补充，定义对字符的处理和波特率，不过这儿初始化的时候太多的判断了，不太清楚)
6. 使用相应的链路规则open tty和o_tty(假如存在的话)
7. 最后是一些错误处理的代码(不在流程里了)

哀叹我的小灵通

倒霉啊，小灵通坏了，修不好啦。客服MM告诉我这个残酷的事实的时候，我无语了。昨天下午专门出去修小灵通，大车都花了30+元，好不容易来到客服，却是修不好了。都怪我自己，自己没事瞎搞，终于玩坏了。不知道怎么了，可能我比较衰，大学以后买的手机，小灵通，电脑一个接一个的坏，真是霉运啊。小灵通坏了也就忍了，我想把机器停机了吧，可是身份证还找不到了，估计前段时间收拾的时候给消失了，还得补办，麻烦了啊。

哎，我就是一个衰人！！！

reading tty_io.c

reading usr/src/linux-source-2.6.17/drivers/char/tty_io.c
TTYAUX_MAJOR,0 5,0 /dev/tty 当前进程的"控制终端"
TTYAUX_MAJOR,1 5,1 /dev/console 控制台
TTY_MAJOR,0 4,0 /dev/tty0 当前虚拟控制台
在打开ttyS0的时候，选项O_NOCTTY 表示不能把本串口当成控制终端，否则用户的键盘输入信息将影响程序的执行。
function done
static int tty_open(struct inode * inode, struct file * filp)

reading《Linux 2.6内核的精彩世界》

reading《Linux 2.6内核的精彩世界》
http://www-128.ibm.com/developerworks/cn/linux/kernel/
l-kernel26/index.html
1,模块子系统 - 设备驱动程序
在 Linux 2.6的开发历程中，模块子系统是另一有重大改进的部分。许多代码被重写，以提高稳定性，并使系统更加透明。除了这些明显的表层的变化之外，还有更多背后的内核如何看待以及使用模块的改变。
首先，Linux 2.6中内核驱动程序最显而易见的（虽然并没有太大作用）的变化是文件扩展名改变了。".ko"（kernel object，内核目标文件）取代了".o"（这是一目标文件的常见扩展名，通常在程序编译期间，链接生成可执行应用程序之前
完完全全实质性的改进在于消除存在于很多内核版本中的竞态的多方面工作。问题的关键在于，如果卸载发生在模块检查并确认没有其它的设备正在使用它之后，使用一个正在被卸载的模块来启动设备是有可能的。新的内核模块代码应使得这一条件更难被触发。
更加透明是新的模块子系统另一特性。在此之前，几乎所有的 Linux版本中，模块是足够智能的，它们可以通过扫描总线寻找它识别（recognized）的设备ID号，检测到它所能够支持的设备（比如PCI， ISA PnP以及PC卡）。Linux 2.6标准化了这种支持，使之对内

2,sys文件系统
最明显的用户可见的改变可能是新的sysfs文件系统的出现，它集成了下面3种文件系统的信息：针对进程信息的proc文件系统、针对设备的devfs文件系统以及针对伪终端的devpts文件系统。该文件系统（安装在/sys目录）是核心看到的设备树的一个直观反映。核

既然每个设备（或者说内核对象）在sysfs中都有唯一对应的目录结构，那么下一步可以把设备的属性（设备名，电源模式，中断处理等）信息输出到这个目录树中以供系统管理员读写。相应的，很多跟设备相关的/proc/sys的用法已经或者将要移到/sys目录下。