Linux内核大讲堂 (二) 传说中的字符设备(3)

       接下来讲的是字符设备的重点，就是从用户空间调用open最到终调用我们写的字符驱动中的open的整个过程。下面的讨论将会非常有意思，请大家一定要看完所有的描述，否则理解有问题就别怪哥没提醒你了！

       在这之前我们大概说说大名鼎鼎的系统调用，从字面上理解就是系统（内核）提供的调用（服务），取小括号里面的话就拼成了：内核提供的服务。这个服务是通过一条int 0x80指令来实现的，利用这条指令可以产生一个软件中断，所谓的软件中断就是执行软件指令产生的一个假中断，这个假中断是相对于硬中断而言的。通过产生的假中断，我们可以做一个用户态到内核态的切换。就拥有了内核的执行权限。懂点底层的玩家都知道有什么ring0,ring1,ring2之类的， Arm玩家应该也知道ARM9体系的CPU有7种工作模式。Linux内核就是利用了CPU的这种特性来实现内核态和用户态的划分。你要用CPU的特性，那当然要符合CPU定制的游戏规则罗。int这条指令所对应的机器码就是CPU制定的游戏规则。这个游戏规则就可以实现CPU工作模式的切换，在linux下就可以实现用户态到内核态的切换，而我们一些伟大的先人发现机器码不好记，易出错，所以就做了一个符号与这机器码一一对应，这些符号就就是今天大家所熟知的汇编指令。当年要换了我们去玩计算机的话，要一天到晚敲0101，我想大家也肯定不会愿意，也肯定会想些助记符来替换0101。如果换了是我的话，我肯定会把中断指令所对应机器码的指令名写成:wwhsint。让wwhs受后人敬仰，想不认识哥都难。^_^，但我们伟大的先人境界很高，为了让大家少敲4个字母就直接取名int（难道这就是传说中的无厘头解释？）。好了，用户态到内核态的切换已经完成了。

我们上面的推导是正确的吗？

我要告诉大家，不见得！我自已都差点被骗了。经过哥反汇编后，发现我本机的open系统调用并不是所谓的通过int 0x80来实现的。那到底是怎么实现的呢？你想知道吗？哥满足你强烈的求知欲。接下来这一段旅程将会非常有意思！请打起精神来。

下面是哥本机open函数的反汇编结果：

(gdb) disassemble open

Dump of assembler code for function open:

0x0072b1d0 <open+0>:    cmpl   $0x0,%gs:0xc

0x0072b1d8 <open+8>:    jne    0x72b1fc <open+44>

0x0072b1da <__open_nocancel+0>: push   %ebx

0x0072b1db <__open_nocancel+1>: mov    0x10(%esp),%edx

0x0072b1df <__open_nocancel+5>: mov    0xc(%esp),%ecx

0x0072b1e3 <__open_nocancel+9>: mov    0x8(%esp),%ebx

0x0072b1e7 <__open_nocancel+13>:        mov    $0x5,%eax

0x0072b1ec <__open_nocancel+18>:        call   *%gs:0x10

0x0072b1f3 <__open_nocancel+25>:        pop    %ebx

0x0072b1f4 <__open_nocancel+26>:        cmp    $0xfffff001,%eax

0x0072b1f9 <__open_nocancel+31>:        jae    0x72b22d <open+93>

0x0072b1fb <__open_nocancel+33>:        ret   

0x0072b1fc <open+44>:   call   0x747720 <__libc_enable_asynccancel>

0x0072b201 <open+49>:   push   %eax

0x0072b202 <open+50>:   push   %ebx

0x0072b203 <open+51>:   mov    0x14(%esp),%edx

0x0072b207 <open+55>:   mov    0x10(%esp),%ecx

0x0072b20b <open+59>:   mov    0xc(%esp),%ebx

0x0072b20f <open+63>:   mov    $0x5,%eax

0x0072b214 <open+68>:   call   *%gs:0x10

0x0072b21b <open+75>:   pop    %ebx

0x0072b21c <open+76>:   xchg   %eax,(%esp)

0x0072b21f <open+79>:   call   0x7476e0 <__libc_disable_asynccancel>

0x0072b224 <open+84>:   pop    %eax

0x0072b225 <open+85>:   cmp    $0xfffff001,%eax

0x0072b22a <open+90>:   jae    0x72b22d <open+93>

0x0072b22c <open+92>:   ret   

0x0072b22d <open+93>:   call   0x7742e8 <__i686.get_pc_thunk.cx>

0x0072b232 <open+98>:   add    $0x7edc2,%ecx

0x0072b238 <open+104>:  mov    -0x20(%ecx),%ecx

0x0072b23e <open+110>:  xor    %edx,%edx

0x0072b240 <open+112>:  sub    %eax,%edx

0x0072b242 <open+114>:  mov    %edx,%gs:(%ecx)

0x0072b245 <open+117>:  or     $0xffffffff,%eax

0x0072b248 <open+120>:  jmp    0x72b22c <open+92>

End of assembler dump.

 

通篇看不到传说中的int 0x80！很明显调open是glibc中函数，那就调一下吧。我调啊调，调啊调，调了一会后，终于看到了有价值的东西：__kernel_vsyscall。继续反汇编__kernel_vsyscall：

(gdb)  disassemble __kernel_vsyscall

Dump of assembler code for function __kernel_vsyscall:

0xb77dd414 <__kernel_vsyscall+0>:       push   %ecx

0xb77dd415 <__kernel_vsyscall+1>:       push   %edx

0xb77dd416 <__kernel_vsyscall+2>:       push   %ebp

0xb77dd417 <__kernel_vsyscall+3>:       mov    %esp,%ebp

0xb77dd419 <__kernel_vsyscall+5>:       sysenter

0xb77dd41b <__kernel_vsyscall+7>:       nop   

0xb77dd41c <__kernel_vsyscall+8>:       nop   

0xb77dd41d <__kernel_vsyscall+9>:       nop   

0xb77dd41e <__kernel_vsyscall+10>:      nop   

0xb77dd41f <__kernel_vsyscall+11>:      nop   

0xb77dd420 <__kernel_vsyscall+12>:      nop   

0xb77dd421 <__kernel_vsyscall+13>:      nop   

0xb77dd422 <__kernel_vsyscall+14>:      jmp    0xb77dd417 <__kernel_vsyscall+3>

0xb77dd424 <__kernel_vsyscall+16>:      pop    %ebp

0xb77dd425 <__kernel_vsyscall+17>:      pop    %edx

0xb77dd426 <__kernel_vsyscall+18>:      pop    %ecx

0xb77dd427 <__kernel_vsyscall+19>:      ret   

End of assembler dump.

咦！？sysenter？？？

有点像，汇编哥也不熟，只好google啦！经过google以后，这是我们的linus大神整出来的。这东西是对传统系统调用的优化。下面这是从IBM网站上找到的原话：sysenter 指令用于由 Ring3 进入 Ring0，SYSEXIT 指令用于由 Ring0 返回 Ring3。由于没有特权级别检查的处理，也没有压栈的操作，所以执行速度比 INT n/IRET 快了不少!（但哥发现exit是使用int 0x80的，还有别的系统调用是否用int 0x80我没试，这个也不重要了）调用sysenter指令最终会跳转到汇编代码sysenter_do_call这个section中。（中间的细节处理就别抠了）

sysenter_do_call:

       cmpl $(nr_syscalls), %eax

       jae syscall_badsys

       call *sys_call_table(,%eax,4)

       movl %eax,PT_EAX(%esp)

       LOCKDEP_SYS_EXIT

       DISABLE_INTERRUPTS(CLBR_ANY)

       TRACE_IRQS_OFF

       movl TI_flags(%ebp), %ecx

       testl $_TIF_ALLWORK_MASK, %ecx

       jne sysexit_audit

终于又找到老朋友了！看：call *sys_call_table(,%eax,4)

sys_call_table是啥东西不知道？不会吧，哥们你out了！

ENTRY(sys_call_table)

       .long sys_restart_syscall /* 0 - old "setup()" system call, used for restarting */

       .long sys_exit

       .long ptregs_fork

       .long sys_read

       .long sys_write

       .long sys_open              /* 5 */

明白了吗？还不明白？.long是四个字节，对应了call指令的后面那个4，eax对应的就是偏移号，比如open的话就是5。call sys_call_table + 5*4就跳转到sys_open了。他娘的，linux内核中的技巧真的是无处不在，换了是哥的设计的话，可能就是这样了：

定义一个数字与函数的条目，然后根据条目的数量N定义一张大表，调用的时候再来个哈希。并且哥肯定认为这效率已经很高了。与linux内核比起来，效率基本是一样的，时间复杂度都是O（1），但是我这样处理的话相对于linux内核的处理就多用掉了N*4个字节。如果有N等于256的话。哥就直接多浪费了1K！功力就是在细微处体现的，各位千万不要以为自已天下第一，在公司开发的项目当中如果你看了别人写的代码很别扭的话，千万不要在心里问候人家的祖宗，说不定人家水平很高，可能是你自已水平不够不会欣赏而已。哥当年工作一半年左右的时候是很高调的，感觉敲代码不过如此，现在回头想想，真是幼稚的可以了！

好了，接下来我们看年sys_open。

sys_open在哪呢？linux的潜规则又来了，这个就靠摸索了，我非常不建议大家一有问题就去翻书，上网找资料。你要去源码里面找，或者自已想办法调试。不过这里哥已经帮你找好了。

SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, int, mode)

{

       long ret;

 

       if (force_o_largefile())

              flags |= O_LARGEFILE;

 

       ret = do_sys_open(AT_FDCWD, filename, flags, mode);

       /* avoid REGPARM breakage on x86: */

       asmlinkage_protect(3, ret, filename, flags, mode);

       return ret;

}

不明白？帖几个宏给你看一下就明白了。

第一个宏：

#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)

第二个宏：

#define SYSCALL_DEFINEx(x, sname, ...)                            /

       __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

第三个宏：

#define __SYSCALL_DEFINEx(x, name, ...)                                 /

       asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))

其实就是用一个##把sys与我们传入的open 连起来了。

一定要在学习内核的过程中不断提升自已的分析调试能力，这才是我们学内核的目的，不要为了学内核而学内核！

       我们先回到函数：

SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, int, mode)

{

       long ret;

 

       if (force_o_largefile())

              flags |= O_LARGEFILE;

 

       ret = do_sys_open(AT_FDCWD, filename, flags, mode);

       /* avoid REGPARM breakage on x86: */

       asmlinkage_protect(3, ret, filename, flags, mode);

       return ret;

}

显然最重要的是do_sys_open(AT_FDCWD, filename, flags, mode);

long do_sys_open(int dfd, const char __user *filename, int flags, int mode)

{

       char *tmp = getname(filename);//获取文件名，因为传进来的字符串位于用户空间

       int fd = PTR_ERR(tmp);

 

       if (!IS_ERR(tmp)) {

              fd = get_unused_fd_flags(flags);

              if (fd >= 0) {

                     struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);

                     if (IS_ERR(f)) {

                            put_unused_fd(fd);

                            fd = PTR_ERR(f);

                     } else {

                            fsnotify_open(f);

                            fd_install(fd, f);

                     }

              }

              putname(tmp);

       }

       return fd;

}

麻烦的事情终于来了。我们避不开了。

先来看看fd,看看大家天天用的fd到底是个啥玩意。

#define get_unused_fd_flags(flags) alloc_fd(0, (flags))

再看看alloc_fd:

int alloc_fd(unsigned start, unsigned flags)

{

       struct files_struct *files = current->files;

       unsigned int fd;

       int error;

       struct fdtable *fdt;

 

       spin_lock(&files->file_lock);

repeat:

       fdt = files_fdtable(files);

       fd = start;

       if (fd < files->next_fd)

              fd = files->next_fd;

 

       if (fd < fdt->max_fds)

              fd = find_next_zero_bit(fdt->open_fds->fds_bits,

                                      fdt->max_fds, fd);

 

       error = expand_files(files, fd);

       if (error < 0)

              goto out;

 

       /*

        * If we needed to expand the fs array we

        * might have blocked - try again.

        */

       if (error)

              goto repeat;

 

       if (start <= files->next_fd)

              files->next_fd = fd + 1;

 

       FD_SET(fd, fdt->open_fds);

       if (flags & O_CLOEXEC)

              FD_SET(fd, fdt->close_on_exec);

       else

              FD_CLR(fd, fdt->close_on_exec);

       error = fd;

#if 1

       /* Sanity check */

       if (rcu_dereference_raw(fdt->fd[fd]) != NULL) {

              printk(KERN_WARNING "alloc_fd: slot %d not NULL!/n", fd);

              rcu_assign_pointer(fdt->fd[fd], NULL);

       }

#endif

 

out:

       spin_unlock(&files->file_lock);

       return error;

}

首先解释一下struct files_struct *files = current->files;

current是一个宏：

#define current get_current()

利用这个宏我们可以取得当前进程的任务结构体，任务结构体中有一个成员：

struct files_struct *files;这个东东包含了与文件相关的一大堆东东，首先里面有个成员叫next_fd,每当open一个文件经就自加1。然后还定义了一个叫open_fds的位图，每个位表示对应数值的文件，比如第1位，表示fd为1的文件，第100位，表示fd为100的文件。这也是一种比较优秀的设计方法，， <<编译珠玑>>这本书讲到大量不重复的数进行排序时也就利用了这种思想。另外精通网络编程的同志肯定知道名震江湖的select了，select也用到了位图的思想。算法不是本系列的重点，如果不太明白的同志可以查阅相关文档进行学习。

好了，言归正传(我发现我老是容易跑题^_^)，然后在调用alloc_fd()也就是get_unused_fd_flags()时，他就会帮我们分配一个fd,并且在位图中帮我们打上已经占用的标记。真正实现打标记功能的其实就是__FD_SET。

#define __FD_SET(fd,fdsetp)                                   /

       asm volatile("btsl %1,%0":                        /

                   "+m" (*(__kernel_fd_set *)(fdsetp))   /

                   : "r" ((int)(fd)))

不懂汇编的同志不用急，这个是GCC提供的内嵌汇编，也不难，可以参照相关的文档花一两个小时学习一下就差不多了。这里我说一下我的学习方法：汇编的指令我是从来不记的，用到了就查一下，我人本来就笨，记性又不好，所以能不记的东西我是从来不记的。

接下来就是do_filp_open(dfd, tmp, flags, mode, 0);

接下来我直接给出调用顺序，（文件系统后面会有专题进行分析）

do_filp_open()-> finish_open()-> nameidata_to_filp()-> __dentry_open()

接下来我们看看__dentry_open():

static struct file *__dentry_open(struct dentry *dentry, struct vfsmount *mnt,

                                   struct file *f,

                                   int (*open)(struct inode *, struct file *),

                                   const struct cred *cred)

{

       struct inode *inode;

       int error;

 

       f->f_mode = OPEN_FMODE(f->f_flags) | FMODE_LSEEK |

                            FMODE_PREAD | FMODE_PWRITE;

       inode = dentry->d_inode;

       if (f->f_mode & FMODE_WRITE) {

              error = __get_file_write_access(inode, mnt);

              if (error)

                     goto cleanup_file;

              if (!special_file(inode->i_mode))

                     file_take_write(f);

       }

 

       f->f_mapping = inode->i_mapping;

       f->f_path.dentry = dentry;

       f->f_path.mnt = mnt;

       f->f_pos = 0;

       f->f_op = fops_get(inode->i_fop);

       file_sb_list_add(f, inode->i_sb);

 

       error = security_dentry_open(f, cred);

       if (error)

              goto cleanup_all;

 

       if (!open && f->f_op)

              open = f->f_op->open;

       if (open) {

              error = open(inode, f);

              if (error)

                     goto cleanup_all;

       }

       ima_counts_get(f);

 

       f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);

 

       file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);

 

       /* NB: we're sure to have correct a_ops only after f_op->open */

       if (f->f_flags & O_DIRECT) {

              if (!f->f_mapping->a_ops ||

                  ((!f->f_mapping->a_ops->direct_IO) &&

                  (!f->f_mapping->a_ops->get_xip_mem))) {

                     fput(f);

                     f = ERR_PTR(-EINVAL);

              }

       }

 

       return f;

 

cleanup_all:

       fops_put(f->f_op);

       if (f->f_mode & FMODE_WRITE) {

              put_write_access(inode);

              if (!special_file(inode->i_mode)) {

                     /*

                      * We don't consider this a real

                      * mnt_want/drop_write() pair

                      * because it all happenend right

                      * here, so just reset the state.

                      */

                     file_reset_write(f);

                     mnt_drop_write(mnt);

              }

       }

       file_sb_list_del(f);

       f->f_path.dentry = NULL;

       f->f_path.mnt = NULL;

cleanup_file:

       put_filp(f);

       dput(dentry);

       mntput(mnt);

       return ERR_PTR(error);

}

看到了吗？

if (!open && f->f_op)

              open = f->f_op->open; //这就是我们之前注册的wwhs_open()

       if (open) {

              error = open(inode, f);

              if (error)

                     goto cleanup_all;

 

好了，虽然有很多细节我们没有详细分析，但是open函数从用户空间到我们最终的wwhs_open的整个调用的脉络大家都非常清楚了。read()和write()等函数的调用过程比这个就简单多了。

调用顺序大致如下：

sysenter_do_call()->sys_read()->vfs_read()->wwhs_read()。

字符设备的讲解到这里要告一断落了，是不是感觉打通了一条经脉但另一条经脉又阻塞了？呵呵，该来的总归要来，出来混迟早要还的，我们无论是在讲驱动模型，还是讲字符驱动都避开文件系统没讲，现在调用的脉络及原理大家都清楚了，但细节上的把握还差的很远，要把握住细节，就避不开文件系统，所以下一节就会讲文件系统了！^_^