Monday, 15. January 2007, 13:54:04

Sunday, 25. February 2007, 07:16:44

Linux内核源代码中有这么一个脚本文件：scripts/gcc-version.sh。它的主要代码如下：

     9  compiler=”$*”
    10
    11  MAJOR=$(echo GNUC | $compiler -E -xc - | tail -n 1)
    12  MINOR=$(echo GNUC_MINOR | $compiler -E -xc - | tail -n 1)
    13  printf “%02d%02dn” $MAJOR $MINOR
    14

从上面我们很容易看出它的用法，它要带一个参数，指明该平台上 GNU C编译器的命令（可能有些平台是cc）。它会给出GNU C编译器的版本号，以如下格式：XXYY，其中XX是主版本号，YY是次版本号，比如gcc-4.1的版本号就是0401。

这个脚本的实现很简单，它通过把GNU C编译器预先定义的宏GNUC和GNUC_MINOR展开后交给编译器的预处理器处理，处理后其实就应该是想要的结果了，但gcc会自动在前面插入自己的一些东西，所以，要截取最后一行才是真正的结果。-E选项是指明只进行预处理，注意：如果没有-o，-E默认的输出是标准输出；-x选项是要指明所使用的语言，这里指明的是c；-是说明输入来自标准输入，这主要是照顾管道。

另一个和gcc相关的脚本是scripts/gcc-x86_64-has-stack-protector.sh，它用来测试x86_64（x86_64是AMD的，IA-64才是Intel的）上是不是有堆栈保护，代码如下：

     3  echo “int foo(void) { char X[200]; return 3; }” | $1 -S -xc -c -O0 -mcmodel=kernel -fstack-protector - -o - 2< /dev/null | grep -q “%gs”
     4  if [ “$?” -eq “0” ] ; then
     5          echo $2
     6  fi

-fstack-protector选项是指明要检查堆栈是否会溢出，这是为了保护程序免于缓冲区溢出的攻击；-mcmodel=kernel是指明要为内核模式生成代码，Linux内核似乎要使用此选项。第3行的命令使用得更妙，还把中间命令的错误重定向到了/dev/null，而且还为grep开启了安静模式。似乎是从生成的汇编中找到”%gs”这个寄存器就说明有堆栈保护，但原理还是不明白;-(。

Friday, 2. February 2007, 06:07:27

王聪@西邮
红黑树是平衡二叉树的一种，它有很好的性质，树中的结点都是有序的，而且因为它本身就是平衡的，所以查找也不会出现非常恶劣的情况，基于二叉树的操作的时间复杂度是O(log(n))。Linux内核在管理vm_area_struct时就是采用了红黑树来维护内存块的。

先到include/linux/rbtree.h中看一下rbtree的定义，如下：

struct rb_node
{
        unsigned long  rb_parent_color;
#define RB_RED          0
#define RB_BLACK        1
        struct rb_node *rb_right;
        struct rb_node *rb_left;
} __attribute__((aligned(sizeof(long))));

struct rb_root只是struct rb_node*的一个包装，这样做的好处是看起来不用传递二级指针了。不错，很简单。再看一下下面几个重要的宏，细心的你一定会发现，rb_parent_color其实没那么简单，Andrea Arcangeli在这里使用了一个小的技巧，不过非常棒。正如名字所暗示，这个成员其实包含指向parent的指针和此结点的颜色！它是怎么做到的呢？很简单，对齐起了作用。既然是sizeof(long)大小的对齐，那么在IA-32上，任何rb_node结构体的地址的低两位肯定都是零，与其空着不用，还不如用它们表示颜色，反正颜色就两种，其实只要一位就够了（估计此处也是照顾16位的机器）。 这样，提取parent指针只要把rb_parent_color成员的低两位清零即可：

#define rb_parent(r)   ((struct rb_node *)((r)-

取颜色只要看最后一位即可：

#define rb_color(r)   ((r)-

测试颜色和设置颜色也是水到渠成的事了。需要特别指出的是下面的一个内联函数：

static inline void rb_link_node(struct rb_node * node, struct rb_node * parent, struct rb_node ** rb_link);

它把parent设为node的父结点，并且让rb_link指向node。 我们把重点集中在lib/rbtree.c上，看看一些和红黑树相关的重要算法。开始之前我们一起回忆一下红黑树的规则： 1\. 每个结点要么是红色要么是黑色； 2\. 根结点必须是黑色； 3\. 红结点如果有孩子，其孩子必须都是黑色； 4\. 从根结点到叶子的每条路径必须包含相同数目的黑结点。 这四条规则可以限制一棵排序树是平衡的。 __rb_rotate_left是把以root为根的树中的node结点进行左旋，__rb_rotate_right是进行右旋。这两个函数是为后面的插入和删除服务，而不是为外部提供接口。 新插入的结点都设为叶子，染成红色，插入后如果破坏了上述规则，通过调整颜色和旋转可以恢复，二叉树又重新平衡。插入操作的接口函数是

void rb_insert_color(struct rb_node *node, struct rb_root *root);

它把已确定父结点的node结点融入到以root为根的红黑树中，具体算法的分析可以参考MIT的《算法导论》第14.3节，这里的实现和书中的讲解几乎完全一样！怎么确定node的父结点应该在调用rb_insert_color之前通过手工迭带完成。值得指出的一点是，虽然插入操作需要一个循环迭代，但是总的旋转次数不会超过两次！所以效率还是很乐观的。 删除操作多多少少都有点麻烦，它要先执行像普通二叉查找树的“删除”，然后根据删除结点的颜色来判断是否执行进一步的操作。删除的接口是

void rb_erase(struct rb_node *node, struct rb_root *root);

其实它并没有真正删除node，而只是让它和以root为根的树脱离关系，最后它还要判断是否调用__rb_erase_color来调整。具体算法的讲解看参考《算法导论》13.3和14.4节，__rb_erase_color对应书中的RB-DELETE-FIXUP。此处的实现和书上也基本上一致。 其余的几个接口就比较简单了。

struct rb_node *rb_first(struct rb_root *root);

在以root为根的树中找出并返回最小的那个结点，只要从根结点一直向左走就是了。

struct rb_node *rb_last(struct rb_root *root);

是找出并返回最大的那个，一直向右走。

struct rb_node *rb_next(struct rb_node *node);

返回node在树中的后继，这个稍微复杂一点。如果node的右孩子不为空，它只要返回node的右子树中最小的结点即可；如果为空，它要向上查找，找到迭带结点是其父亲的左孩子的结点，返回父结点。如果一直上述到了根结点，返回NULL。

struct rb_node *rb_prev(struct rb_node *node);

返回node的前驱，和rb_next中的操作对称。

void rb_replace_node(struct rb_node *victim, struct rb_node *new, struct rb_root *root);

用new替换以root为根的树中的victim结点。 红黑树接口使用的一个典型例子如下：

static inline struct page * rb_search_page_cache(struct inode * inode,
                                                 unsigned long offset)
{
        struct rb_node * n = inode-_
        struct page * page;

        while (n)
        {
                page = rb_entry(n, struct page, rb_page_cache);

                if (offset > page-
                        n = n-
                else if (offset < page-
                        n = n-
                else
                        return page;
        }
        return NULL;
}

static inline struct page * __rb_insert_page_cache(struct inode * inode,
                                                   unsigned long offset,
                                                   struct rb_node * node)
{
        struct rb_node ** p = &inode-
        struct rb_node * parent = NULL;
        struct page * page;

        while (*p)
        {
                parent = *p;
                page = rb_entry(parent, struct page, rb_page_cache);

                if (offset > page-
                        p = &(*p)-
                else if (offset < page-
                        p = &(*p)-
                else
                        return page;
        }

        rb_link_node(node, parent, p);

        return NULL;
}

static inline struct page * rb_insert_page_cache(struct inode * inode,
                                                 unsigned long offset,
                                                 struct rb_node * node)
{
        struct page * ret;
        if ((ret = __rb_insert_page_cache(inode, offset, node)))
                goto out;
        rb_insert_color(node, &inode-
 out:
        return ret;
}
_

Friday, 2. February 2007, 05:58:24

王聪@西邮

Linux内核中大量使用了队列，这里仅列举它在进程管理中的几处应用。

状态为TASK_RUNNING的进程都会被放入运行队列（runqueue）中，这是通过task_struct（定义在include/linux/sched.h）中的run_list成员来链接的。不过，为了让内核每次都能选取优先级最合适的进程，Linux为每个优先级构建了一个queue！这是通过struct prio_array来实现的，struct prio_array的定义（在kernel/sched.c）大致如下：

struct prio_array {
int nr_active;
unsigned long bitmap[BITMAP_SIZE];
struct list_head queue[MAX_PRIO];
};

queue成员就是队列数组。每个CPU有各自的runqueue，每一个runqueue又有包含两个prio_array，一个是活动队列，一个是时间片耗尽的队列。当运行队列空时，内核便会交换两个队列的指针！原来的耗尽队列就成了新的活动队列！这和prio_array中的bitmap是决定调度算法为O(1)的关键！

状态为TASK_STOPPED，EXIT_ZOMBIE或EXIT_DEAD的进程不会被放入专门的队列中，它们直接通过pid或者通过父进程的孩子队列来访问。

TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE状态的进程会被放入等待队列。不同的是，每个等待事件都会有一个等待队列，该队列中的进程等待同一事件的完成（不要惊慌！“事件”一个动态的过程，不好通过具体的结构来定义一个“事件”。这里等待一个事件就是查看某个条件是否为真，比如某个标志变量是否为真。）。wait_queue_head_t的定义（include/linux/wait.h）如下：

typedef struct _ _wait_queue_head {
        spinlock_t lock;
        struct list_head task_list;
    }wait_queue_head_t;

wait_queue_t的定义如下：

typedef struct _ _wait_queue {
        unsigned int flags;
        struct task_struct  task;
        wait_queue_func_t func;
        struct list_head task_list;
    }wait_queue_t;

进入等待状态的接口有两类：
prepare_to_wait()/finish_wait()
wait_event()
其实wait_event()内部也是调用prepare_to_wait()，把它放入一个循环中。而且wait_event()在事件完成时会自动调用finish_wait()。决定使用哪个要看情况而定。sleep_on*()是遗弃的接口，现在已经不再使用，虽然还支持。等待队列中的进程有两种，一种是exclusive的进程，另一种是nonexclusive的进程。所谓exclusive是指唤醒的进程等待的资源是互斥的，每次只唤醒一个（唤醒多个也可以，不过最后还是只有一个会被唤醒，其余的又被重新添加到等待队列中，这样效率会大打折扣）。一般，等待函数会把进程设为nonexclusive和uninterruptible，带“interruptible”的会专门指定状态为interruptible；而带“timeout”的会在超时后退出，因为它会调用schedule_timeout()；带“exclusive”的则会把进程设为exclusive。

唤醒的接口虽然只有wake_up*()，但它内部也分成好几种。带“interruptible”的唤醒函数只会唤醒状态是TASK_INTERRUPTIBLE的进程，而不带的则会唤醒TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE的进程；所有唤醒函数都会把等待同一事件的nonexclusive进程全部唤醒，或者把其中一个exclusive的进程唤醒；而带“nr”的则会唤醒指定个数的exclusive的进程，带“all”的会把全部exclusive进程唤醒。带“sync”会忽略优先级的检查，高优先级的进程可能会被延迟。最后，持有自旋锁时只能调用wait_up_locked()。