菜鸟 个人记录 2024-11-25T15:34:34.641Z http://example.com/ John Doe Hexo IIC总线驱动 http://example.com/posts/IIC%E6%80%BB%E7%BA%BF%E9%A9%B1%E5%8A%A8.html 2024-11-25T15:33:19.000Z 2024-11-25T15:34:34.641Z platform总线驱动 http://example.com/posts/platform%E6%80%BB%E7%BA%BF%E9%A9%B1%E5%8A%A8.html 2024-11-25T15:33:19.000Z 2024-11-25T15:34:58.013Z 内核字符操作函数 http://example.com/posts/%E5%86%85%E6%A0%B8%E5%AD%97%E7%AC%A6%E6%93%8D%E4%BD%9C%E5%87%BD%E6%95%B0.html 2024-11-25T15:33:19.000Z 2024-11-25T15:36:10.528Z 字符设备驱动创建流程 http://example.com/posts/%E5%AD%97%E7%AC%A6%E8%AE%BE%E5%A4%87%E9%A9%B1%E5%8A%A8%E5%88%9B%E5%BB%BA%E6%B5%81%E7%A8%8B.html 2024-11-25T15:33:19.000Z 2024-11-25T15:35:34.385Z 设备驱动总线模型 http://example.com/posts/%E8%AE%BE%E5%A4%87%E9%A9%B1%E5%8A%A8%E6%80%BB%E7%BA%BF%E6%A8%A1%E5%9E%8B.html 2024-11-25T15:33:19.000Z 2024-11-25T15:33:49.858Z kobject
ktype
kset

kobject_create_and_add函数等

]]> <p>kobject<br>ktype<br>kset</p> <p>kobject_create_and_add函数等</p> Linux内核内存管理 http://example.com/posts/Linux%E5%86%85%E6%A0%B8%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86.html 2024-11-25T15:30:49.000Z 2024-11-25T15:32:38.171Z Linux内核进程管理&进程调度 http://example.com/posts/Linux%E5%86%85%E6%A0%B8%E8%BF%9B%E7%A8%8B%E7%AE%A1%E7%90%86-%E8%BF%9B%E7%A8%8B%E8%B0%83%E5%BA%A6.html 2024-11-25T15:30:49.000Z 2024-11-25T15:32:53.635Z slab MMU TLB等

]]> <p>slab MMU TLB等</p> 内核文件系统&VFS http://example.com/posts/%E5%86%85%E6%A0%B8%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F-VFS.html 2024-11-25T15:29:53.000Z 2024-11-25T15:30:16.987Z 等待队列 http://example.com/posts/%E7%AD%89%E5%BE%85%E9%98%9F%E5%88%97.html 2024-11-25T15:20:39.000Z 2024-11-25T15:21:11.300Z 一、Linux等待队列概述

Linux内核的等待队列（Wait Queue）是重要的数据结构，与进程调度机制紧密相关联，可以用来同步对系统资源的访问、异步事件通知、跨进程通信等。

在Linux中，等待队列以循环链表为基础结构，包括两种数据结构：等待队列头(wait queue head)和等待队列元素(wait queue)，整个等待队列由等待队列头进行管理。下文将用内核源码（基于Linux kernel 5.2）对等待队列进行介绍，详细说明采用等待队列实现进程阻塞和唤醒的方法。

二、等待队列头和等待队列元素

等待队列以循环链表为基础结构，链表头和链表项分别为等待队列头和等待队列元素，分别用结构体 wait_queue_head_t 和 wait_queue_entry_t 描述（定义在 linux/wait.h ）。

2.1 基本概念

1
2
3
4
5
struct wait_queue_head {
    spinlock_t          lock;
    struct list_head    head;
};
typedef struct wait_queue_head wait_queue_head_t;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
typedef int (*wait_queue_func_t)(struct wait_queue_entry *wq_entry, unsigned mode, int flags, void *key);
int default_wake_function(struct wait_queue_entry *wq_entry, unsigned mode, int flags, void *key);
/* wait_queue_entry::flags */
#define WQ_FLAG_EXCLUSIVE   0x01
#define WQ_FLAG_WOKEN       0x02
#define WQ_FLAG_BOOKMARK    0x04
/*
 * A single wait-queue entry structure:
 */
struct wait_queue_entry {
    unsigned int        flags;
    void                *private;
    wait_queue_func_t   func;
    struct list_head    entry;
};

typedef struct wait_queue_entry wait_queue_entry_t;

等待队列头结构包括一个自旋锁和一个链表头。等待队列元素除了包括链表项，还包括：

  • flags : 标识队列元素状态和属性
  • *private: 用于指向关联进程 task_struct 结构体的指针
    • func : 函数指针，用于指向等待队列被唤醒时的回调的唤醒函数

以进程阻塞和唤醒的过程为例，等待队列的使用场景可以简述为：

进程 A 因等待某些资源（依赖进程 B 的某些操作）而不得不进入阻塞状态，便将当前进程加入到等待队列 Q 中。进程 B 在一系列操作后，可通知进程 A 所需资源已到位，便调用唤醒函数 wake up 来唤醒等待队列上 Q 的进程，注意此时所有等待在队列 Q 上的进程均被置为可运行状态。

借助上述描述场景，说明等待队列元素属性 flags 标志的作用，下文也将结合源码进行详细解读。

(1) WQ_FLAG_EXCLUSIVE

上述场景中看到，当某进程调用 wake up 函数唤醒等待队列时，队列上所有的进程均被唤醒，在某些场合会出现唤醒的所有进程中，只有某个进程获得了期望的资源，而其他进程由于资源被占用不得不再次进入休眠。如果等待队列中进程数量庞大时，该行为将影响系统性能。

内核增加了”独占等待”(WQ_FLAG_EXCLUSIVE)来解决此类问题。一个独占等待的行为和通常的休眠类似，但有如下两个重要的不同：

等待队列元素设置 WQ_FLAG_EXCLUSIVE 标志时，会被添加到等待队列的尾部，而非头部。

在某等待队列上调用 wake up 时，执行独占等待的进程每次只会唤醒其中第一个（所有非独占等待进程仍会被同时唤醒）。

(2) WQ_FLAG_WOKEN

暂时还未理解，TODO

(3) WQ_FLAG_BOOKMARK

用于 wake_up() 唤醒等待队列时实现分段遍历，减少单次对自旋锁的占用时间。

三、 等待队列的创建和初始化

等待队列头的定义和初始化有两种方式： init_waitqueue_head(&wq_head) 和宏定义 DECLARE_WAIT_QUEUE_HEAD(name) 。

1
2
3
4
5
6
7
8
9
10
11
12
#define init_waitqueue_head(wq_head)                            \
    do {                                                        \
        static struct lock_class_key __key;                     \
        __init_waitqueue_head((wq_head), #wq_head, &__key);     \
    } while (0)

void __init_waitqueue_head(struct wait_queue_head *wq_head, const char *name, struct lock_class_key *key)
{
    spin_lock_init(&wq_head->lock);
    lockdep_set_class_and_name(&wq_head->lock, key, name);
    INIT_LIST_HEAD(&wq_head->head);
}
1
2
3
4
5
6
#define DECLARE_WAIT_QUEUE_HEAD(name)                       \
    struct wait_queue_head name = __WAIT_QUEUE_HEAD_INITIALIZER(name)

#define __WAIT_QUEUE_HEAD_INITIALIZER(name) {               \
    .lock       = __SPIN_LOCK_UNLOCKED(name.lock),          \
    .head       = { &(name).head, &(name).head } }

四、等待队列元素的创建和初始化

创建等待队列元素较为普遍的一种方式是调用宏定义 DECLARE_WAITQUEUE(name, task) ，将定义一个名为 name 的等待队列元素， private 数据指向给定的关联进程结构体 task ，唤醒函数为 default_wake_function() 。后文介绍唤醒细节时详细介绍唤醒函数的工作。

1
2
3
4
5
6
7
#define DECLARE_WAITQUEUE(name, tsk)                        \
    struct wait_queue_entry name = __WAITQUEUE_INITIALIZER(name, tsk)

#define __WAITQUEUE_INITIALIZER(name, tsk) {                \
    .private    = tsk,                                      \
    .func       = default_wake_function,                    \
    .entry      = { NULL, NULL } }

内核源码中还存在其他定义等待队列元素的方式，调用宏定义 DEFINE_WAIT(name) 和 init_wait(&wait_queue) 。

这两种方式都将当前进程(current)关联到所定义的等待队列上，唤醒函数为 autoremove_wake_function() ，注意此函数与上述宏定义方式时不同（上述定义中使用 default_wake_function() ）。

下文也将介绍 DEFINE_WAIT() 和 DECLARE_WAITQUEUE() 在使用场合上的不同。

1
2
3
4
5
6
7
#define DEFINE_WAIT(name)   DEFINE_WAIT_FUNC(name, autoremove_wake_function)
#define DEFINE_WAIT_FUNC(name, function)                    \
    struct wait_queue_entry name = {                        \
        .private    = current,                              \
        .func       = function,                             \
        .entry      = LIST_HEAD_INIT((name).entry),         \
    }
1
2
3
4
5
6
7
#define init_wait(wait)                                     \
    do {                                                    \
        (wait)->private = current;                          \
        (wait)->func = autoremove_wake_function;            \
        INIT_LIST_HEAD(&(wait)->entry);                     \
        (wait)->flags = 0;                                  \
    } while (0)

五、添加和移除等待队列

内核提供了两个函数（定义在 kernel/sched/wait.c ）用于将等待队列元素 wq_entry 添加到等待队列 wq_head 中： add_wait_queue() 和 add_wait_queue_exclusive() 。

add_wait_queue() ：在等待队列头部添加普通的等待队列元素（非独占等待，清除 WQ_FLAG_EXCLUSIVE 标志）。

add_wait_queue_exclusive() ：在等待队列尾部添加独占等待队列元素（设置了 WQ_FLAG_EXCLUSIVE 标志）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    unsigned long flags;
    // 清除WQ_FLAG_EXCLUSIVE标志
    wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
    spin_lock_irqsave(&wq_head->lock, flags);
    __add_wait_queue(wq_head, wq_entry);
    spin_unlock_irqrestore(&wq_head->lock, flags);
}   

static inline void __add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    list_add(&wq_entry->entry, &wq_head->head);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
void add_wait_queue_exclusive(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    unsigned long flags;
    // 设置WQ_FLAG_EXCLUSIVE标志
    wq_entry->flags |= WQ_FLAG_EXCLUSIVE;
    spin_lock_irqsave(&wq_head->lock, flags);
    __add_wait_queue_entry_tail(wq_head, wq_entry);
    spin_unlock_irqrestore(&wq_head->lock, flags);
}

static inline void __add_wait_queue_entry_tail(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    list_add_tail(&wq_entry->entry, &wq_head->head);
}

remove_wait_queue() 函数用于将等待队列元素 wq_entry 从等待队列 wq_head 中移除。

1
2
3
4
5
6
7
8
9
10
11
12
13
void remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    unsigned long flags;
    spin_lock_irqsave(&wq_head->lock, flags);
    __remove_wait_queue(wq_head, wq_entry);
    spin_unlock_irqrestore(&wq_head->lock, flags);
}

static inline void
__remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    list_del(&wq_entry->entry);
}

添加和移除等待队列的示意图如下所示：

六、等待事件

内核中提供了等待事件 wait_event() 宏（以及它的几个变种），可用于实现简单的进程休眠，等待直至某个条件成立，主要包括如下几个定义：

wait_event(wq_head, condition)
wait_event_timeout(wq_head, condition, timeout)
wait_event_interruptible(wq_head, condition)
wait_event_interruptible_timeout(wq_head, condition, timeout)
io_wait_event(wq_head, condition)

上述所有形式函数中， wq_head 是等待队列头（采用”值传递“的方式传输函数）， condition 是任意一个布尔表达式。使用 wait_event ，进程将被置于非中断休眠，而使用 wait_event_interruptible 时，进程可以被信号中断。

另外两个版本 wait_event_timeout 和 wait_event_interruptible_timeout 会使进程只等待限定的时间（以jiffy表示，给定时间到期时，宏均会返回0，而无论 condition 为何值）。

详细介绍 wait_event() 函数的实现原理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
#define wait_event(wq_head, condition)                      \
    do {                                                    \
        might_sleep();                                      \
        // 如果condition满足，提前返回                       \
        if (condition)                                      \
           break;                                           \
        __wait_event(wq_head, condition);                   \
    } while (0)

#define __wait_event(wq_head, condition)                    \
     (void)___wait_event(wq_head, condition, TASK_UNINTERRUPTIBLE, 0, 0, schedule())

/* 定义等待队列元素，并将元素加入到等待队列中
 * 循环判断等待条件condition是否满足，若条件满足，或者接收到中断信号，等待结束，函数返回
 * 若condition满足，返回0；否则返回-ERESTARTSYS
 */

#define ___wait_event(wq_head, condition, state, exclusive, ret, cmd)       \
({                                                          \
     __label__ __out;                                       \
     struct wait_queue_entry __wq_entry;                    \
     long __ret = ret;          /* explicit shadow */       \
                                                            \
     // 初始化等待队列元素__wq_entry，关联当前进程，根据exclusive参数初始化属性标志 \
     // 唤醒函数为autoremove_wake_function()                                        \
     init_wait_entry(&__wq_entry, exclusive ? WQ_FLAG_EXCLUSIVE : 0);    \
     // 等待事件循环                                        \
     for (;;) {                                             \
        // 如果进程可被信号中断并且刚好有信号挂起，返回-ERESTARTSYS     \
        // 否则，将等待队列元素加入等待队列，并且设置进程状态，返回0    \
        long __int = prepare_to_wait_event(&wq_head, &__wq_entry, state);\
                                                           \
        // 当前进程让出调度器前，判断condition是否成立。若成立，提前结束，后续将返回0   \
        if (condition)                                      \
            break;                                          \
                                                            \
        // 当前进程让出调度器前，判断当前进程是否接收到中断信号（或KILL信号）       \
        // 如果成立，将提前返回-ERESTARTSYS                 \
        if (___wait_is_interruptible(state) && __int) {     \
            __ret = __int;                                  \
            goto __out;                                     \
        }                                                   \
                                                           \
        // 此处实际执行schedule()，当前进程让出调度器       \
        cmd;                                                \
     }                                                      \

     // 设置进程为可运行状态，并且将等待队列元素从等待队列中删除    \
     finish_wait(&wq_head, &__wq_entry);                    \
     __out:  __ret;                                         \
})  

void init_wait_entry(struct wait_queue_entry *wq_entry, int flags) 
{
    wq_entry->flags = flags;
    wq_entry->private = current;
    wq_entry->func = autoremove_wake_function;
    INIT_LIST_HEAD(&wq_entry->entry);
}

long prepare_to_wait_event(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry, int state)
{
    unsigned long flags;
    long ret = 0;
    spin_lock_irqsave(&wq_head->lock, flags);
    // 返回非0值条件：可被信号中断并且确实有信号挂起
    if (signal_pending_state(state, current)) {
        // 将等待队列元素从等待队列中删除，返回-ERESTARTSYS
        list_del_init(&wq_entry->entry);
        ret = -ERESTARTSYS;
    } else {
        // 判断wq_entry->entry是否为空，即等待队列元素是否已经被添加到等待队列中
        if (list_empty(&wq_entry->entry)) {
            // WQ_FLAG_EXCLUSIVE标志被设置时，将等待队列元素添加到等待队列尾部（独占等待）
            // 否则，将等待队列元素添加到等待队列头部。同2.1中对WQ_FLAG_EXCLUSIVE标志介绍。
            if (wq_entry->flags & WQ_FLAG_EXCLUSIVE)
                __add_wait_queue_entry_tail(wq_head, wq_entry);
            else
                __add_wait_queue(wq_head, wq_entry);
        }
        // 改变当前进程的状态
        set_current_state(state);
    }
    spin_unlock_irqrestore(&wq_head->lock, flags);
    return ret;
}

// 用state_value改变当前的进程状态，并且执行了一次内存屏障
// 注意，只是改变了调度器处理该进程的方式，但尚未使该进程让出处理器
#define set_current_state(state_value)              \
    do {                            \
        WARN_ON_ONCE(is_special_task_state(state_value));\
        current->task_state_change = _THIS_IP_;     \
        smp_store_mb(current->state, (state_value));    \
    } while (0)

/*  设置进程为可运行状态，并且将等待队列元素从等待队列中删除  */
void finish_wait(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
{
    unsigned long flags;
    // 将当前进程状态改为可运行状态(TASK_RUNNING)
    // 类似set_current_state()，差别在于未进行内存屏障
    __set_current_state(TASK_RUNNING);
    // 等待队列元素若仍在等待队列中，则将其删除
    if (!list_empty_careful(&wq_entry->entry)) {
        spin_lock_irqsave(&wq_head->lock, flags);
        list_del_init(&wq_entry->entry);
        spin_unlock_irqrestore(&wq_head->lock, flags);
    }
}

经过源码分析可以看到， wait_event 使进程进入非中断休眠状态，循环等待直至特定条件满足，否则进程继续保持休眠状态。

可以简单总结出使用等待队列使进程休眠的一般步骤：

  • 将当前进程关联的等待队列元素加入到等待队列中。 __add_wait_queue()/__add_wait_queue_entry_tail()
  • 设置当前进程状态（可中断 TASK_INTERRUPTIBLE 或不可中断 TASK_UNINTERRUPTIBLE）。 set_current_state()
  • 判断资源是否得到，或是否捕获中断信号。
  • 进程让出调度器，进入休眠状态。 schedule()
  • 资源得到满足时，将等待队列元素从等待队列中移除。

七、等待队列唤醒

前文已经简单提到， wake_up 函数可用于将等待队列上的所有进程唤醒，和 wait_event 相对应， wake_up 函数也包括多个变体。主要包括：

wake_up(&wq_head)
wake_up_interruptible(&wq_head)
wake_up_nr(&wq_head, nr)
wake_up_interruptible_nr(&wq_head, nr)
wake_up_interruptible_all(&wq_head)

wake_up()

wake_up() 可以用来唤醒等待队列上的所有进程，而 wake_up_interruptible() 只会唤醒那些执行可中断休眠的进程。因此约定， wait_event() 和 wake_up() 搭配使用，而 wait_event_interruptible() 和 wake_up_interruptible() 搭配使用。

前文提到，对于独占等待的进程， wake_up() 只会唤醒第一个独占等待进程。 wake_up_nr() 函数提供功能，它能唤醒给定数目nr个独占等待进程，而不是只有一个。

wake_up() 函数的实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
#define TASK_NORMAL         (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
// 可以看出wake_up函数将唤醒TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE的所有进程
#define wake_up(x)          __wake_up(x, TASK_NORMAL, 1, NULL)
void __wake_up(struct wait_queue_head *wq_head, unsigned int mode, int nr_exclusive, void *key)
{
    __wake_up_common_lock(wq_head, mode, nr_exclusive, 0, key);
}

static void __wake_up_common_lock(struct wait_queue_head *wq_head, unsigned int mode,
        int nr_exclusive, int wake_flags, void *key)
{
    unsigned long flags;
    wait_queue_entry_t bookmark;
    bookmark.flags = 0;
    bookmark.private = NULL;
    bookmark.func = NULL;
    INIT_LIST_HEAD(&bookmark.entry);
    // 第一次尝试调用__wake_up_common()，如果需要进行BOOKMARK过程，bookmark.flags会被置为WQ_FLAG_BOOKMARK
    spin_lock_irqsave(&wq_head->lock, flags);
    nr_exclusive = __wake_up_common(wq_head, mode, nr_exclusive, wake_flags, key, &bookmark);
    spin_unlock_irqrestore(&wq_head->lock, flags);
    // 如果还有需要处理的元素，那么bookmark.flags肯定置上WQ_FLAG_BOOKMARK；否则，在一个loop内便处理完成
    while (bookmark.flags & WQ_FLAG_BOOKMARK) {
        spin_lock_irqsave(&wq_head->lock, flags);
        nr_exclusive = __wake_up_common(wq_head, mode, nr_exclusive, wake_flags, key, &bookmark);
        spin_unlock_irqrestore(&wq_head->lock, flags);
    }
}

#define WAITQUEUE_WALK_BREAK_CNT 64
static int __wake_up_common(struct wait_queue_head *wq_head, unsigned int mode,
        int nr_exclusive, int wake_flags, void *key, wait_queue_entry_t *bookmark)
{
    wait_queue_entry_t *curr, *next;
    int cnt = 0;
    // 判断自旋锁已经被持有
    lockdep_assert_held(&wq_head->lock);
    // 如果bookmark元素中标志`WQ_FLAG_BOOKMARK`已被设置，则curr被设置为bookmark下一个元素
    // 同时将bookmark从等待队列中删除，bookmark->flags清零
    // 否则，curr设置为等待队列wq_head的第一个元素（实际上为第一次调用__wake_up_common）
    if (bookmark && (bookmark->flags & WQ_FLAG_BOOKMARK)) {
        curr = list_next_entry(bookmark, entry);
        list_del(&bookmark->entry);
        bookmark->flags = 0;
    } else
        curr = list_first_entry(&wq_head->head, wait_queue_entry_t, entry);
    if (&curr->entry == &wq_head->head)
        return nr_exclusive;
    // 在等待队列头指向的链表上，从curr指向的元素开始依次遍历元素
    list_for_each_entry_safe_from(curr, next, &wq_head->head, entry) {
        unsigned flags = curr->flags;
        int ret;
        // 跳过标记为WQ_FLAG_BOOKMARK的元素，等待队列元素被置上WQ_FLAG_BOOKMARK？
        if (flags & WQ_FLAG_BOOKMARK)
            continue;
        // 调用等待队列元素绑定的唤醒回调函数
        // 注意，具体唤醒何种进程(TASK_INTERRUPTIBLE/TASK_UNINTERRUPTIBLE)，作为参数传递给唤醒函数处理
        // 当进程不符合唤醒条件时，ret为0，详见try_to_wake_up()
        ret = curr->func(curr, mode, wake_flags, key);
        if (ret < 0)
            break;
        // 如果当前等待队列元素为独占等待，并且独占等待个数已经等于nr_exclusive，提前退出循环
        // 如2.1所述，独占等待进程被加入到等待队列的尾部，因此此时表明所有唤醒工作已经完成
        if (ret && (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
            break;
        // 连续唤醒的进程数目达到指定数目WAITQUEUE_WALK_BREAK_CNT（仍有进程元素需要处理），
        // 标记bookmark->flags为WQ_FLAG_BOOKMARK，同时将下一个要处理的元素添加到bookmark作为头节点的链表尾部，并退出遍历循环
        // 通过这种机制，实现了进程分批次唤醒，避免了等待队列中自旋锁被持有时间过长
        if (bookmark && (++cnt > WAITQUEUE_WALK_BREAK_CNT) &&
                (&next->entry != &wq_head->head)) {
            bookmark->flags = WQ_FLAG_BOOKMARK;
            list_add_tail(&bookmark->entry, &next->entry);
            break;
        }
    }
    return nr_exclusive;
}

wake_up() 函数会遍历等待队列上的所有元素（包括TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE)），根据 nr_exclusive 参数的要求唤醒进程，同时实现了分批次唤醒工作。最终会回调等待队列元素所绑定的唤醒函数。

前文已经提到，定义等待队列元素时主要涉及到两种唤醒回调函数：

  • default_wake_function() ：宏定义 DECLARE_WAITQUEUE(name, tsk) 使用的唤醒函数。

  • autoremove_wake_function() ： DEFINE_WAIT(name) ， init_wait(wait) 和 wait_event() 中调用的 init_wait_entry() 使用此唤醒函数。

default_wake_function()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
int default_wake_function(wait_queue_entry_t *curr, unsigned mode, int wake_flags, void *key)
{
    return try_to_wake_up(curr->private, mode, wake_flags);
}

static int
try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
{
    unsigned long flags;
    int cpu, success = 0;
    raw_spin_lock_irqsave(&p->pi_lock, flags);
    smp_mb__after_spinlock();
    // 此处对进程的状态进行筛选，跳过不符合状态的进程（TASK_INTERRUPTIBLE/TASK_UNINTERRUPTIBLE）
    if (!(p->state & state))
        goto out;
    trace_sched_waking(p);
    /* We're going to change ->state: */
    success = 1;
    cpu = task_cpu(p);
    smp_rmb();
    if (p->on_rq && ttwu_remote(p, wake_flags))
        goto stat;
    ... ...
    // Try-To-Wake-Up
    ttwu_queue(p, cpu, wake_flags);
stat:
    ttwu_stat(p, cpu, wake_flags);
out:
    raw_spin_unlock_irqrestore(&p->pi_lock, flags);
    return success;
}

static void ttwu_queue(struct task_struct *p, int cpu, int wake_flags)
{
    struct rq *rq = cpu_rq(cpu);
    struct rq_flags rf;
    ... ...
    rq_lock(rq, &rf);
    update_rq_clock(rq);
    ttwu_do_activate(rq, p, wake_flags, &rf);
    rq_unlock(rq, &rf);
}

static void
ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags,
        struct rq_flags *rf)
{
    int en_flags = ENQUEUE_WAKEUP | ENQUEUE_NOCLOCK;
    lockdep_assert_held(&rq->lock);
    ... ...
    activate_task(rq, p, en_flags);
    ttwu_do_wakeup(rq, p, wake_flags, rf);
}

/*
 * Mark the task runnable and perform wakeup-preemption.
 */
static void ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags,
        struct rq_flags *rf)
{
    check_preempt_curr(rq, p, wake_flags);
    p->state = TASK_RUNNING;
    trace_sched_wakeup(p);
    ... ...
}

从函数调用过程中可以看到， default_wake_function() 实现唤醒进程的过程为：

default_wake_function() –> try_to_wake_up() –> ttwu_queue() –> ttwu_do_activate() –> ttwu_do_wakeup()

值得一提的是， default_wake_function() 的实现中并未将等待队列元素从等待队列中删除。因此，编写程序时不能忘记添加步骤将等待队列元素从等待队列元素中删除。

autoremove_wake_function()

1
2
3
4
5
6
7
int autoremove_wake_function(struct wait_queue_entry *wq_entry, unsigned mode, int sync, void *key)
{
    int ret = default_wake_function(wq_entry, mode, sync, key);
    if (ret)
        list_del_init(&wq_entry->entry);
    return ret;
}

autoremove_wake_function() 相比于 default_wake_function() ，在成功执行进程唤醒工作后，会自动将等待队列元素从等待队列中移除。

]]> <h3 id="一、Linux等待队列概述"><a href="#一、Linux等待队列概述" class="headerlink" title="一、Linux等待队列概述"></a>一、Linux等待队列概述</h3><p>Linux内核的等待队列（Wait Queue）是重 module_init宏详解&insmod流程&THIS_MODULE http://example.com/posts/module-init%E5%AE%8F%E8%AF%A6%E8%A7%A3-insmod%E6%B5%81%E7%A8%8B-THIS-MODULE.html 2024-11-25T15:19:20.000Z 2024-11-25T15:19:39.596Z 一个模块可以编译进内核，和内核一起打包，也可以作为一个单独模块，单独加载，如ko，本节以ko为例

以最简单的例子讲解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// //helloworld.c

#include <linux/kernel.h>
#include <linux/module.h>

//内核模块初始化函数
static int __init hello_init(void)
{
  printk("Hello World\n");
  return 0;
}

//内核模块退出函数
static void __exit hello_exit(void)
{
  printk("exit\n");
}

module_init(hello_init);
module_exit(hello_exit);

MODULE_LICENSE("GPL");

一、一个特殊的段.gnu.linkonce.this_module section(THIS_MODULE定义)

当我们编译生成.ko模块时，会在该目录下产生这样一个附加文件helloworld.mod.c，这个文件内容如下：
其实THIS_MODULE在内核的定义就是__this_module，通过这个宏就能拿到本模块的一些信息

1
2
3
4
5
6
7
8
9
10
11
// helloworld.mod.c

__visible struct module __this_module
__section(".gnu.linkonce.this_module") = {
  .name = KBUILD_MODNAME,
  .init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
  .exit = cleanup_module,
#endif
  .arch = MODULE_ARCH_INIT,
};

这个后缀为.mod.c的文件会初始化模块 struct module 的这几个成员：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct module {
  ......
  /* Unique handle for this module */
  char name[MODULE_NAME_LEN];

  /* Startup function. */
  int (*init)(void);

  /* Destruction function. */
  void (*exit)(void);

  /* Arch-specific module values */
  struct mod_arch_specific arch;
  ......
}

通过__section(“.gnu.linkonce.this_module”)我们可以知道将该struct module实例添加到内核模块ELF文件中“.gnu.linkonce.this_module”section中。

1
readelf -S helloworld.ko

二、初始化和清理函数

初始化和清理函数

在这里我们发现.mod.c后缀文件的模块初始化函数和清理函数名字是init_module和cleanup_module，而我们编写的内核模块程序中是module_init和module_exit：

1
2
.init = init_module,
.exit = cleanup_module,
1
2
module_init(hello_init);
module_exit(hello_exit);

接下来咱们一起看看module_init源码实现细节：

三、module_init的定义

其实module_init在内核中<linux/module.h>中有两个定义，通过MODULE宏来区分，在咱们编译ko时，使用的命令通常如下：

1
make -C $(KDIR) M=$(PWD) modules

这时会进入内核源码树的顶层Makefile下查找modules目标协助编译，MODULE宏的定义是由内核顶层的Makefile和script/Makefile.lib配合实现的

Makefile

1
2
KBUILD_AFLAGS_MODULE  := -DMODULE
KBUILD_CFLAGS_MODULE  := -DMODULE

scripts/Makefile.lib

1
2
3
4
5
6
part-of-module = $(if $(filter $(basename $@).o, $(real-obj-m)),y)
quiet_modtag = $(if $(part-of-module),[M],   )
modkern_cflags =                                          \
       $(if $(part-of-module),                           \
                $(KBUILD_CFLAGS_MODULE) $(CFLAGS_MODULE), \
                $(KBUILD_CFLAGS_KERNEL) $(CFLAGS_KERNEL) $(modfile_flags))

$@ 表示正在编译的目标，如果是 module 的一部分，则使用 KBUILD_CFLAGS_MODULE 作为 cflags ，即 -DMODULE 被引入 gcc 命令行

此时module_init实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// linux-4.10.1/include/linux/module.h

/* Each module must use one module_init(). */
#define module_init(initfn)          \
  static inline initcall_t __inittest(void)\
  { return initfn; }\
  int init_module(void) __attribute__((alias(#initfn)));

/* This is only required if you want to be unloadable. */
#define module_exit(exitfn)          \
  static inline exitcall_t __exittest(void)\
  { return exitfn; }\
  void cleanup_module(void) __attribute__((alias(#exitfn)));

这使用了gcc提供的别名属性（attribute(alias)）：
将init_module函数的别名设置为initfn，而initfn就是我们模块程序中的初始化函数。
将cleanup_module的别名设置为exitfn，而exitfn就是我们模块程序的清理函数。

四、__init函数和__exit函数

定义如下：

1
2
#define __init    __section(.init.text) __cold notrace __latent_entropy
#define __exit      __section(.exit.text) __exitused __cold notrace

这两个前缀是为了将初始化函数和清理函数放置在ko二进制文件正确的section中。

五、insmod流程

insmod对应的是busybox的一个命令，可以看busybox中的insmod_main函数中的具体实现，这里简单描述一下：

insmod将ko文件使用mmap映射，获取到地址，然后通过系统调用SYSCALL_DEFINE3进入内核

1
2
3
4
SYSCALL_DEFINE3(init_module)
  -->load_module()
    -->layout_and_allocate()
      -->setup_load_info()

load_module中会把.gnu.linkonce.this_module section中的内容初始化给 struct module，然后通过一些列操作，重定位等，获取到.init_text中的位置，最后调用进去，也就是调用到了module_init中的函数，也就是本例中的hello_init。至此ko加载成功，hello_init函数执行

]]> <p>一个模块可以编译进内核，和内核一起打包，也可以作为一个单独模块，单独加载，如ko，本节以ko为例</p> <p>以最简单的例子讲解：</p> <figure class="highlight c"><table><tr><td class="gutter"><pre><sp Linux内核的initcall机制 http://example.com/posts/Linux%E5%86%85%E6%A0%B8%E7%9A%84initcall%E6%9C%BA%E5%88%B6.html 2024-11-25T15:17:08.000Z 2024-11-25T15:17:37.868Z 从根文件系统的挂载说起吧，使能了initd小文件系统的OS，最终会调用到populate_rootfs执行解压挂载的操作，搜索populate最终看到是rootfs_initcall被执行到的，那就从此处开始说起吧，看看内核是如何执行到这个函数的

一、initcall函数调用流程

调用链如下：

1
2
3
4
5
6
7
8
9
10
init/main.c
调用链如下：
 
start_kernel()
    ---->arch_call_rest_init()
        ---->rest_init()
            ---->kernel_init()
                ---->kernel_init_freeable()
                    ---->do_basic_setup()
                        ---->do_initcalls()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
static initcall_entry_t *initcall_levels[] __initdata = {
  __initcall0_start,
  __initcall1_start,
  __initcall2_start,
  __initcall3_start,
  __initcall4_start,
  __initcall5_start,
  __initcall6_start,
  __initcall7_start,
  __initcall_end,
};
 
static void __init do_initcalls(void)
{
  int level;
 
  for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
    do_initcall_level(level);
}

for 循环针对一个指针数组轮询，该数组是一个静态的 initcall_entry_t 类型，这些数据都存放在 __initdata 段。

指针数组的类型为 initcall_entry_t，是 initcall_t 的另一种叫法

继续来看下这个指针数组中的元素：__initcall0_start ~ __initcall_end，而这些元素的值在本c文件中已经声明：

1
2
3
4
5
6
7
8
9
10
11
12
init/main.c
 
extern initcall_entry_t __initcall_start[];
extern initcall_entry_t __initcall0_start[];
extern initcall_entry_t __initcall1_start[];
extern initcall_entry_t __initcall2_start[];
extern initcall_entry_t __initcall3_start[];
extern initcall_entry_t __initcall4_start[];
extern initcall_entry_t __initcall5_start[];
extern initcall_entry_t __initcall6_start[];
extern initcall_entry_t __initcall7_start[];
extern initcall_entry_t __initcall_end[];

不难看出，数组 initcall_levels 中元素存放的是这些函数指针数组的首地址。

那么这些实际的指针数组是在哪里呢？从上文得知，initcall 函数都会被定义成 static initcall_t 类型，并且保存在 .initcall##level##.init 段中，那么 initcall_levels 与其是怎么关联的呢？

答案在 vmlinux.lds.h 中。

二、vmlinux.lds.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
include/asm-generic/vmlinux.lds.h
 
#define INIT_CALLS_LEVEL(level)            \
    __initcall##level##_start = .;\
    KEEP(*(.initcall##level##.init))\
    KEEP(*(.initcall##level##s.init))\
#define INIT_CALLS              \
    __initcall_start = .;\
    KEEP(*(.initcallearly.init))\
    INIT_CALLS_LEVEL(0)\
    INIT_CALLS_LEVEL(1)\
    INIT_CALLS_LEVEL(2)\
    INIT_CALLS_LEVEL(3)\
    INIT_CALLS_LEVEL(4)\
    INIT_CALLS_LEVEL(5)\
    INIT_CALLS_LEVEL(rootfs)\
    INIT_CALLS_LEVEL(6)\
    INIT_CALLS_LEVEL(7)\
    __initcall_end = .;

在这里首先定义了__initcall_start，将其关联到”.initcallearly.init”段。

然后对每个level定义了INIT_CALLS_LEVEL(level)，将INIT_CALLS_LEVEL(level)展开之后的结果是定义__initcall##level##_start，并将__initcall##level##_start关联到”.initcall##level##.init”段和”.initcall##level##s.init”段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
__initcall_start = .;           \
*(.initcallearly.init)          \
__initcall0_start = .;          \
*(.initcall0.init)              \
*(.initcall0s.init)             \
// 省略1、2、3、4、5
__initcallrootfs_start = .;     \
*(.initcallrootfs.init)         \
*(.initcallrootfss.init)            \
__initcall6_start = .;          \
*(.initcall6.init)              \
*(.initcall6s.init)             \
__initcall7_start = .;          \
*(.initcall7.init)              \
*(.initcall7s.init)             \
__initcall_end = .;

上面这些代码段最终在kernel.img中按先后顺序组织，也就决定了位于其中的一些函数的执行先后顺序。

在 kernel_init() 初始化完成后，会调用 free_initmem() 对内核 init 段的内存进行释放处理。即 .init 或者 .initcalls 段在内核启动完毕后，这个段中的内存会被释放掉。

三、do_initcall_level

do_initcall_level函数定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
init/main.c
 
static void __init do_initcall_level(int level)
{
  initcall_entry_t *fn;
 
  strcpy(initcall_command_line, saved_command_line);
  parse_args(initcall_level_names[level],
       initcall_command_line, __start___param,
       __stop___param - __start___param,
       level, level,
       NULL, &repair_env_string);
 
  trace_initcall_level(initcall_level_names[level]);
  for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
    do_one_initcall(initcall_from_entry(fn));
}

do_initcall_level() 函数的参数 level 是之前是initcall_levels 数组的索引，从第0个开始。

这里再用一个 for 循环，跳到 initcall_levels 内部元素 (函数指针数组)进行轮询，fn 初始值为函数指针数组的起始地址，后面 fn++ 相当于函数指针 +1，即跳到下一个函数指针。

即for 循环中，根据传入的 level，确定需要轮询的 .initcall##level##.init 段的所有函数指针，一直到下一个 .intcall##(level+1)##.init 段。

另外，需要注意 do_one_initcall() 的参数就是获取函数指针的内容，而这个内容就是注册进来的 initcall 的实际初始化函数。

如上面的举例：

1
rootfs_initcall(populate_rootfs);

这里最终就看成调用 do_one_initcall(populate_rootfs)；

1
2
3
4
5
6
7
8
9
10
init/main.c
 
int __init_or_module do_one_initcall(initcall_t fn)
{
  ...

  ret = fn();
  ...
  return ret;
}

四、initcall源码

上文提到过 Linux 对驱动程序提供静态编译进内核和动态加载两种方式，Linux 的 initcall 机制也是根据静态编译和动态加载的两种方式选择不同的编译、运行流程。

1
2
3
4
5
6
7
8
9
10
11
include/linux/init.h
 
#ifndef MODULE
 
... //静态加载
 
#else
 
... //动态加载
 
#endif

MODULE 是在编译的时候，通过编译器参数来传入。例如，在编译 ko 时会使用如下两个编译选项，如果是链接到内核，则不会使用：

1
2
3
4
//Makefile
 
KBUILD_AFLAGS_MODULE  := -DMODULE
KBUILD_CFLAGS_MODULE  := -DMODULE

通过 MODULE 的配置，选择静态编译还是动态加载。

本文将只分析静态编译流程

内核中定义的initcall如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
include/linux/init.h
 
 
/*
 * Early initcalls run before initializing SMP.
 *
 * Only for built-in code, not modules.
 */
#define early_initcall(fn)    __define_initcall(fn, early)
 
/*
 * A "pure" initcall has no dependencies on anything else, and purely
 * initializes variables that couldn't be statically initialized.
 *
 * This only exists for built-in code, not for modules.
 * Keep main.c:initcall_level_names[] in sync.
 */
#define pure_initcall(fn)    __define_initcall(fn, 0)
 
#define core_initcall(fn)    __define_initcall(fn, 1)
#define core_initcall_sync(fn)    __define_initcall(fn, 1s)
#define postcore_initcall(fn)    __define_initcall(fn, 2)
#define postcore_initcall_sync(fn)  __define_initcall(fn, 2s)
#define arch_initcall(fn)    __define_initcall(fn, 3)
#define arch_initcall_sync(fn)    __define_initcall(fn, 3s)
#define subsys_initcall(fn)    __define_initcall(fn, 4)
#define subsys_initcall_sync(fn)  __define_initcall(fn, 4s)
#define fs_initcall(fn)      __define_initcall(fn, 5)
#define fs_initcall_sync(fn)    __define_initcall(fn, 5s)
#define rootfs_initcall(fn)    __define_initcall(fn, rootfs)
#define device_initcall(fn)    __define_initcall(fn, 6)
#define device_initcall_sync(fn)  __define_initcall(fn, 6s)
#define late_initcall(fn)    __define_initcall(fn, 7)
#define late_initcall_sync(fn)    __define_initcall(fn, 7s)
 
#define __initcall(fn) device_initcall(fn)
 
#define __exitcall(fn)            \
  static exitcall_t __exitcall_##fn __exit_call = fn
 
#define console_initcall(fn)  ___define_initcall(fn, con, .con_initcall)

对于静态编译 initcall 接口如上，其中 pure_initcall() 只能在静态编译中存在。

当然，对于静态编译的驱动也可以调佣 module_init() 接口：

1
2
3
4
5
include/linux/module.h
 
#define module_init(x)  __initcall(x);
 
#define module_exit(x)  __exitcall(x);

module_init在内核中是有两种定义的，module_init定义在<linux/module.h>中，当包含此头文件的代码中，没有定义MODULE宏时，module_init定义为initcall形式

五、initcall级别

1
2
3
4
5
6
7
8
9
10
11
early-->
0-->0s-->
1-->1s-->
2-->2s-->
3-->3s-->
4-->4s-->
5-->5s-->
rootfs-->
6-->6s-->
7-->7s-->
console

__define_initcall实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
include/linux/init.h
 
#ifdef CONFIG_LTO_CLANG
  /*
   * With LTO, the compiler doesn't necessarily obey link order for
   * initcalls, and the initcall variable needs to be globally unique
   * to avoid naming collisions.  In order to preserve the correct
   * order, we add each variable into its own section and generate a
   * linker script (in scripts/link-vmlinux.sh) to ensure the order
   * remains correct.  We also add a __COUNTER__ prefix to the name,
   * so we can retain the order of initcalls within each compilation
   * unit, and __LINE__ to make the names more unique.
   */
  #define ___lto_initcall(c, l, fn, id, __sec) \
  static initcall_t __initcall_##c##_##l##_##fn##id __used \
    __attribute__((__section__( #__sec \
      __stringify(.init..##c##_##l##_##fn)))) = fn;
  #define __lto_initcall(c, l, fn, id, __sec) \
  ___lto_initcall(c, l, fn, id, __sec)
 
  #define ___define_initcall(fn, id, __sec) \
  __lto_initcall(__COUNTER__, __LINE__, fn, id, __sec)
#else
  #define ___define_initcall(fn, id, __sec) \
  static initcall_t __initcall_##fn##id __used \
    __attribute__((__section__(#__sec ".init"))) = fn;
#endif
#endif
 
#define __define_initcall(fn, id) ___define_initcall(fn, id, .initcall##id)

下文会继续细化分析，这里提前提示：

__define_initcall() 其实就是定义了一个 static initcall_t 的函数指针

1
2
3
4
include/linux/init.h
 
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);

六、attribute详解

(1)、__used

1
2
3
include/linux/compiler_attributes.h

#define __used                          __attribute__((__used__))

这是一种 attribute 修饰属性的一种，意思是告诉编译器：这个静态符号在编译的时候，即使没有使用也要保留，不能优化掉。

(2)、__attribute__ ((section(…)))
attribute 是 GNU C 的一大特色，可以用来修饰对象、函数、结构体类型等等。

这里用来修改 section，意思是将作用的函数放入指定的 section name 对应的段中。

(3)、 __stringify()

1
2
3
4
include/linux/stringify.h
 
#define __stringify_1(x...)  #x
#define __stringify(x...)  __stringify_1(x)

将 __stringify() 中内容字符串化。

七、例子

以静态的module_init定义为例：

假如，我们在驱动使用如下接口：

1
module_init(hello_init);

那么，在编译的时候编译器会通过 initcall 接口产生：

1
2
static initcall_t __initcall_1_23_hello_init6 __attribute__(__used) \
    __attribute__((__section__(".initcall6.init..1_23_hello_init"))) = hello_init;

linux 编译后的initcall 函数

查看编译好的 System.map：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
...
ffffffc012032ee0 d __initcall_223_42_trace_init_flags_sys_enterearly
ffffffc012032ee0 D __initcall_start
ffffffc012032ee0 D __setup_end
ffffffc012032ee8 d __initcall_224_66_trace_init_flags_sys_exitearly
ffffffc012032ef0 d __initcall_163_146_cpu_suspend_initearly
ffffffc012032ef8 d __initcall_151_267_asids_initearly
ffffffc012032f00 d __initcall_167_688_spawn_ksoftirqdearly
ffffffc012032f08 d __initcall_343_6656_migration_initearly
...
ffffffc012032f90 d __initcall_312_768_initialize_ptr_randomearly
ffffffc012032f98 D __initcall0_start
ffffffc012032f98 d __initcall_241_771_bpf_jit_charge_init0
ffffffc012032fa0 d __initcall_141_53_init_mmap_min_addr0
ffffffc012032fa8 d __initcall_209_6528_pci_realloc_setup_params0
ffffffc012032fb0 d __initcall_339_1143_net_ns_init0
ffffffc012032fb8 D __initcall1_start
ffffffc012032fb8 d __initcall_160_1437_fpsimd_init1
ffffffc012032fc0 d __initcall_181_669_tagged_addr_init1
...
ffffffc012033178 d __initcall_347_1788_init_default_flow_dissectors1
ffffffc012033180 d __initcall_360_2821_netlink_proto_init1
ffffffc012033188 D __initcall2_start
ffffffc012033188 d __initcall_165_139_debug_monitors_init2
ffffffc012033190 d __initcall_141_333_irq_sysfs_init2
...
ffffffc0120332b8 d __initcall_304_814_kobject_uevent_init2
ffffffc0120332c0 d __initcall_184_1686_msm_rpm_driver_init2s
ffffffc0120332c8 D __initcall3_start
ffffffc0120332c8 d __initcall_173_390_debug_traps_init3
ffffffc0120332d0 d __initcall_161_275_reserve_memblock_reserved_regions3
...
ffffffc012033370 d __initcall_132_5273_gsi_init3
ffffffc012033378 d __initcall_149_547_of_platform_default_populate_init3s
ffffffc012033380 D __initcall4_start
...
ffffffc012033878 D __initcall5_start
...
ffffffc0120339d8 d __initcall_317_1188_xsk_init5
ffffffc0120339e0 d __initcall_211_194_pci_apply_final_quirks5s
ffffffc0120339e8 d __initcall_168_680_populate_rootfsrootfs
ffffffc0120339e8 D __initcallrootfs_start
ffffffc0120339f0 D __initcall6_start
...
ffffffc012034b30 D __initcall7_start
...
ffffffc012034c88 d __initcall_150_554_of_platform_sync_state_init7s
ffffffc012034c90 d __initcall_123_29_alsa_sound_last_init7s
ffffffc012034c98 D __con_initcall_start
ffffffc012034c98 d __initcall_151_246_hvc_console_initcon
ffffffc012034c98 D __initcall_end
ffffffc012034ca0 D __con_initcall_end

从 System.map 得知：

  • 从 __initcall_start ~ __initcall_end 所有函数指针都是连续的，相差8 个字节；
  • __initcall_start 就是第一个 early 级别的 initcall 函数指针，同理 __initcall0_start 就是第一个 level 0 级别的initcall 函数指针，以此类推；
  • rootfs 级别的 initcall 函数是插在 level 5s 之后，level 6 级别之前；
  • console 级别的函数在 level 7s 之后，__initcall_end 之前；
    当然通过命令 readelf 或者 objdump (objdump -h vmlinux.o)都能看到各个字段
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .initcall0.init 00000020  0000000000000000  0000000000000000  00000040  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  1 .initcall1.init 000001d0  0000000000000000  0000000000000000  00000060  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .initcall2.init 00000138  0000000000000000  0000000000000000  00000230  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  3 .initcall2s.init 00000008  0000000000000000  0000000000000000  00000368  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .initcall3.init 000000b0  0000000000000000  0000000000000000  00000370  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  5 .initcall3s.init 00000008  0000000000000000  0000000000000000  00000420  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  6 .initcall4.init 000004f0  0000000000000000  0000000000000000  00000428  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  7 .initcall4s.init 00000008  0000000000000000  0000000000000000  00000918  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  8 .initcall5.init 00000168  0000000000000000  0000000000000000  00000920  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  9 .initcall5s.init 00000008  0000000000000000  0000000000000000  00000a88  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 10 .initcall6.init 00001140  0000000000000000  0000000000000000  00000a90  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 11 .initcall7.init 00000140  0000000000000000  0000000000000000  00001bd0  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 12 .initcall7s.init 00000028  0000000000000000  0000000000000000  00001d10  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 13 .con_initcall.init 00000008  0000000000000000  0000000000000000  00001d38  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 14 .initcallearly.init 000000b8  0000000000000000  0000000000000000  00001d40  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 15 .initcallrootfs.init 00000008  0000000000000000  0000000000000000  00001df8  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
]]> <p>从根文件系统的挂载说起吧，使能了initd小文件系统的OS，最终会调用到populate_rootfs执行解压挂载的操作，搜索populate最终看到是rootfs_initcall被执行到的，那就从此处开始说起吧，看看内核是如何执行到这个函数的</p> <h2 id="一 内核调试 http://example.com/posts/%E5%86%85%E6%A0%B8%E8%B0%83%E8%AF%95.html 2024-11-25T15:16:17.000Z 2024-11-25T15:16:32.766Z echo 7 4 1 7 > /proc/kernel/printk

]]> <p>echo 7 4 1 7 &gt; &#x2F;proc&#x2F;kernel&#x2F;printk</p> 使用proc和sysfs文件系统 http://example.com/posts/%E4%BD%BF%E7%94%A8proc%E5%92%8Csysfs%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F.html 2024-11-25T15:15:30.000Z 2024-11-25T15:15:51.953Z proc目录详解：https://blog.csdn.net/qq_39974998/article/details/130536491

一、DEVICE_ATTR

在调试驱动的时候我们一般会对于驱动中某一个属性或者变量进行操作，或者是控制gpio口，这个时候我们可以在驱动中创建对应的属性，从而在应用程序或者控制台对驱动的属性进行设置,sysfs可以通过sysfs_create_files和sysfs_create_group()来创建，其中使用DEVICE_ATTR来创建属性文件

这个宏定义在kernel/include/linux/device.h中，函数定义为：

1
2
3
4
5
6
7
8
9
#define DEVICE_ATTR(_name, _mode, _show, _store) \
  struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)

#define __ATTR(_name, _mode, _show, _store) {        \
  .attr = {.name = __stringify(_name),\
  .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },\
  .show= _show,\
  .store= _store,\
}

mode为文件的权限，定义在kernel/include/uapi/linux/stat.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#define S_IRWXU 00700 //用户可读写和执行
#define S_IRUSR 00400//用户可读
#define S_IWUSR 00200//用户可写
#define S_IXUSR 00100//用户可执行
 
#define S_IRWXG 00070//用户组可读写和执行
#define S_IRGRP 00040//用户组可读
#define S_IWGRP 00020//用户组可写
#define S_IXGRP 00010//用户组可执行
 
#define S_IRWXO 00007//其他可读写和执行
#define S_IROTH 00004//其他可读
#define S_IWOTH 00002//其他可写
#define S_IXOTH 00001//其他可执行

二、device_attribute

1
2
3
4
5
6
7
8
/* interface for exporting device attributes */
struct device_attribute {
    struct attribute    attr;
    ssize_t (*show)(struct device *dev, struct device_attribute *attr,
            char *buf);
    ssize_t (*store)(struct device *dev, struct device_attribute *attr,
             const char *buf, size_t count);
};

三、创建sysfs文件

法1：sysfs_create_files

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
static ssize_t led_store(struct device *dev,struct device_attribute *attr, const char *buf, size_t len)
{
    printk("led_store()\n");
    return len;//必须返回传入的长度
}

 //下面的show和store只是简单举例
static ssize_t led_show(struct device *dev, struct device_attribute*attr, char *buf)
{
         printk("led_show()\n");
         returnpr_info("store\n");
 }

//用DEVICE_ATTR宏创建属性led_sysfs文件，如果show()或是store()没有功能，就以NULL代替
static DEVICE_ATTR(led_sysfs, S_IWUSR, led_show,led_store);

//最后一项必须以NUll结尾
static const struct attribute *atk_imx6ul_led_sysfs_attrs[] = {
  &dev_attr_led_sysfs.attr,
  NULL,
};

sysfs_create_files(&led_device.device->kobj,atk_imx6ul_led_sysfs_attrs);
sysfs_remove_file(&led_device.device->kobj, atk_imx6ul_led_sysfs_attrs);//驱动退出时释放结点

其中kobj的定义为

1
2
3
4
kobject在设备结构体中的描述：
struct platform_device
     —>struct device dev
        —>struct kobject kobj

法2(推荐)：sysfs_create_group()

使用：将上面的attribute结构体再进行封装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
static ssize_t led_store(struct device *dev,struct device_attribute *attr, const char *buf, size_t len)
{
    printk("led_store()\n");
    return len;//必须返回传入的长度
}

 //下面的show和store只是简单举例
static ssize_t led_show(struct device *dev, struct device_attribute*attr, char *buf)
{
         printk("led_show()\n");
         returnpr_info("store\n");
 }

//用DEVICE_ATTR宏创建属性led_sysfs文件，如果show()或是store()没有功能，就以NULL代替
static DEVICE_ATTR(led_sysfs, S_IWUSR, led_show,led_store);

//最后一项必须以NUll结尾
static struct attribute *atk_imx6ul_led_sysfs_attrs[] = {
  &dev_attr_led_sysfs.attr,
  NULL,
};

static const struct attribute_group dev_attr_grp = {
       .attrs = atk_imx6ul_led_sysfs_attrs,
};
sysfs_create_group(&led_device.device.kobj, &dev_attr_grp) //创建接口
sysfs_remove_group(&client->dev.kobj, &dev_attr_group); //接口移除，在调用remove函数时调用

四、验证

直接在终端下通过find命令查找结点，这里只是一个示例，并不是上面举的例子

实验echo命令调用store函数

这里cat没有写出，实际上直接将上述的echo 1或者echo 0 写成cat就okay了

五、device_create_file

可以在创建驱动时，在创建出来的设备目录下/sys/class/xxx/xxx，新建sysfs文件

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 \* device_create_file - create sysfs attribute file for device.
 \* @dev: device.
 \* @attr: device attribute descriptor.
 */
int device_create_file(struct device *dev, const struct device_attribute *attr)
{
 int error = 0;
 if (dev)
 error = sysfs_create_file(&dev->kobj, &attr->attr);
 return erro

}
]]> <p>proc目录详解：<a href="https://blog.csdn.net/qq_39974998/article/details/130536491">https://blog.csdn.net/qq_39974998/article/details/13053649 内核定时器&hrtime高精度定时器 http://example.com/posts/%E5%86%85%E6%A0%B8%E5%AE%9A%E6%97%B6%E5%99%A8-hrtime%E9%AB%98%E7%B2%BE%E5%BA%A6%E5%AE%9A%E6%97%B6%E5%99%A8.html 2024-11-25T15:14:19.000Z 2024-11-25T15:14:37.003Z 一、定时器初始化

void hrtimer_init(struct hrtimer *timer, clockid_t clock_id, enum hrtimer_mode mode)；

1
2
3
4
5
6
7
8
9
10
参数timer是hrtimer指针，
参数clock_id有如下常用几种选项：
       CLOCK_REALTIME  //实时时间，如果系统时间变了，定时器也会变
       CLOCK_MONOTONIC  //递增时间，不受系统影响
参数mode有如下几种选项：
  HRTIMER_MODE_ABS = 0x0,/* 绝对模式 */
HRTIMER_MODE_REL = 0x1,    /* 相对模式 */
HRTIMER_MODE_PINNED = 0x02,  /* 和CPU绑定 */
HRTIMER_MODE_ABS_PINNED = 0x02, /* 第一种和第三种的结合 */
HRTIMER_MODE_REL_PINNED = 0x03, /* 第二种和第三种的结合 */

二、启动定时器

hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode)；

1
2
3
参数timer是hrtimer指针
参数tim是时间，可以使用ktime_set()函数设置时间，
参数mode和初始化的mode参数一致

三、设置超时时间

1
2
3
4
5
6
7
/*
 * 单位为秒和纳秒组合
 */
ktime_t ktime_set(const long secs, const unsigned long nsecs)；
 
/* 设置超时时间，当定时器超时后可以用该函数设置下一次超时时间 */
hrtimer_forward_now(struct hrtimer *timer, ktime_t interval)

四、设置回调函数

1
2
struct hrtimer timer;
timer.function = hr_callback;

五、关闭定时器

int hrtimer_cancel(struct hrtimer *timer)；

使用例子：hrtimer.c

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/hrtimer.h>
#include <linux/jiffies.h>
 
//定义一个hrtimer
static struct hrtimer timer;
ktime_t kt;
 
//定时器回调函数
static enum hrtimer_restart hrtimer_hander(struct hrtimer *timer)
{
    printk("I am in hrtimer hander\r\n");
    hrtimer_forward(timer,timer->base->get_time(),kt);//hrtimer_forward(timer, now, tick_period);
    return HRTIMER_RESTART;  //重启定时器
}
 
static int __init test_init(void)
{
    printk("---------%s-----------\r\n",__func__);
 
    kt = ktime_set(0,1000000);// 0s  1000000ns  = 1ms 定时
    hrtimer_init(&timer,CLOCK_MONOTONIC,HRTIMER_MODE_REL);
    hrtimer_start(&timer,kt,HRTIMER_MODE_REL);
    timer.function = hrtimer_hander; //此处设置了定时器到时间后的回调函数
    return 0;
}
 
static void __exit test_exit(void)
{
    hrtimer_cancel(&timer);
    printk("------------test over---------------\r\n");
}
 
module_init(test_init);
module_exit(test_exit);
MODULE_LICENSE("GPL");
]]> <h3 id="一、定时器初始化"><a href="#一、定时器初始化" class="headerlink" title="一、定时器初始化"></a>一、定时器初始化</h3><p><code>void hrtimer_init(struct hrtimer *timer, 系统调用流程 http://example.com/posts/%E7%B3%BB%E7%BB%9F%E8%B0%83%E7%94%A8%E6%B5%81%E7%A8%8B.html 2024-11-25T15:13:20.000Z 2024-11-25T15:13:44.426Z 用户态代码通过系统调用可以进入内核态，通过系统调用进入内核态，同时会切换CPU运行模式，保证了用户空间和内核空间不影响。

程序可以请求操作系统提供服务，‌如设备IO操作、‌进程间通信等。‌系统调用运行在内核空间，‌需要更高的执行权限，‌而普通的库函数调用则运行在用户态。‌

Linux系统调用的实现机制涉及多个层面，‌包括用户空间和内核空间的划分、‌系统调用号、‌中断处理、‌以及内核函数的具体实现等。‌在x86架构上，‌系统调用通常通过int 80h指令实现，‌利用系统调用号来区分不同的入口函数。‌在Intel CPU中，‌这个指令由中断0x80实现，‌而在ARM架构中，‌则是通过SWI指令实现。‌

系统调用的基本流程包括：‌

  1. 用户空间的程序通过库函数或者直接的系统调用请求服务。‌
  2. 这些请求通过软件中断（‌在x86上是int $0x80，‌在ARM上是SWI指令）‌陷入内核空间。‌
  3. 内核接收到请求后，‌根据系统调用号查找系统调用表（‌sys_call_table）‌，‌找到对应的内核函数入口地址。‌
  4. 执行内核函数，‌完成请求的服务后，‌返回结果到用户空间。‌

系统调用的优点包括：‌

  • 提供了一种标准化的接口，‌使得用户空间的程序可以以一致的方式请求操作系统服务。‌
  • 由于系统调用在内核空间执行，‌因此可以访问硬件设备等低级资源，‌提供了对硬件的直接控制。‌
  • 通过内核的权限检查，‌提高了系统的安全性。‌

总的来说，‌Linux系统调用是操作系统内核与用户空间程序交互的重要机制，‌它允许用户空间的程序请求操作系统提供各种服务，‌如文件操作、‌进程管理、‌网络通信等，‌从而实现了操作系统的基本功能‌

]]> <p>用户态代码通过系统调用可以进入内核态，通过系统调用进入内核态，同时会切换CPU运行模式，保证了用户空间和内核空间不影响。</p> <p>程序可以请求操作系统提供服务，‌如设备IO操作、‌进程间通信等。‌系统调用运行在内核空间，‌需要更高的执行权限，‌而普通的库函数调用则运行 互斥锁、信号量、原子操作、自旋锁 http://example.com/posts/%E4%BA%92%E6%96%A5%E9%94%81%E3%80%81%E4%BF%A1%E5%8F%B7%E9%87%8F%E3%80%81%E5%8E%9F%E5%AD%90%E6%93%8D%E4%BD%9C%E3%80%81%E8%87%AA%E6%97%8B%E9%94%81.html 2024-11-25T15:12:37.000Z 2024-11-25T15:12:55.639Z linux并发产生的原因
（1）多线程并发访问，
（2）抢占式并发访问，进程调度可以在任意时刻抢占正在运行的线程，从而运行其他的线程
（3）终端程序并发访问
（4）SMP(多核)间并发访问

并发访问的后果就是竞争，一般像全局变量，设备结构体这些肯定是要保护的，至于其他的数据就要根据实际的驱动程序而定了。

一、原子操作

（1）原子操作的原因

对于c语言来说，a=3，编译为汇编语言时可能被翻译成如下汇编（仅作为理解）

1
2
3
ldr r0, =0X30000000 /* 变量 a 地址 */
ldr r1, = 3 /* 要写入的值 */
str r1, [r0] /* 将 3 写入到 a 变量中 */

当并发出现时可能出现这种情况：

(2)原子操作api

为避免上述情况，Linux 内核定义了叫做 atomic_t 的结构体来完成整形数据的原子操作，在使用中用原子变量来代替整形变量，此结构体定义在 include/linux/types.h 文件中，

1
2
3
4
5
6
7
 typedef struct {
   int counter;
 } atomic_t;
 
typedef struct {
  long long counter;
} atomic64_t;//64操作系统

声明变量可以这样，atomic_t a;
linux提供了多个可以对原子变量进行操作的函数，

二、自旋锁

原子操作只能对整形变量或者位进行保护，但是，在实际的使用环境中怎么可能只有整形变量或位这么简单的临界区。举个最简单的例子，设备结构体变量就不是整型变量，我们对于结构体中成员变量的操作也要保证原子性，在线程 A 对结构体变量使用期间，应该禁止其他的线程来访问此结构体变量，这些工作原子操作都不能胜任，需要锁机制，在 Linux内核中就是自旋锁。

当一个线程要访问某个共享资源的时候首先要先获取相应的锁，锁只能被一个线程持有，只要此线程不释放持有的锁，那么其他的线程就不能获取此锁。对于自旋锁而言，如果自旋锁正在被线程 A 持有，线程 B 想要获取自旋锁，那么线程 B 就会处于忙循环-旋转-等待状态，线程 B 不会进入休眠状态或者说去做其他的处理，而是会一直傻傻的在那里“转圈圈”的等待锁可用。

从这里我们可以看到自旋锁的一个缺点：那就等待自旋锁的线程会一直处于自旋状态，这样会浪费处理器时间，降低系统性能，所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁。

1
2
3
4
5
6
7
8
9
10
11
12
13
typedef struct spinlock {
  union {
    struct raw_spinlock rlock;
 
#ifdef CONFIG_DEBUG_LOCK_ALLOC
# define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map))
    struct {
      u8 __padding[LOCK_PADSIZE];
      struct lockdep_map dep_map;
    };
#endif
  };
} spinlock_t;

自旋锁接口函数

自旋锁保护的临界区一定不能调用任何能够引起睡眠和阻塞的API 函数，否则的话会可能会导致死锁现象的发生，经典死锁的发生例子：

线程a在持有锁期间进入了休眠，被调度出去，此时线程b想要获取锁，但是锁被线程a持有，并且内核抢占被禁止了，线程b无法调度出去一直等待锁被释放，而线程a此时也无法再次被调度运行，死锁就发生了。

还有就是中断里使用锁的时候也一定注意死锁的发生，例如

线程 A 先运行，并且获取到了 lock 这个锁，当线程 A 运行 functionA 函数的时候中断发生了，中断抢走了 CPU 使用权。右边的中断服务函数也要获取 lock 这个锁，但是这个锁被线程 A 占有着，中断就会一直自旋，等待锁有效。

最好的解决方法就是获取锁之前关闭本地中断

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DEFINE_SPINLOCK(lock) /* 定义并初始化一个锁 */
 
 /* 线程 A */
 void functionA (){
 unsigned long flags; /* 中断状态 */
 spin_lock_irqsave(&lock, flags) /* 是在这里禁止本地中断，并获取锁 */
 /* 临界区 */
 spin_unlock_irqrestore(&lock, flags)  /* 释放锁 */
 }
 
 /* 中断服务函数 */
 void irq() {
 spin_lock(&lock) /* 获取锁 */
 /* 临界区 */
 spin_unlock(&lock) /* 释放锁 */
 }

自旋锁的使用注意事项；

（1）因为在等待自旋锁的时候处于“自旋”状态，因此锁的持有时间不能太长，一定要
短，否则的话会降低系统性能。如果临界区比较大，运行时间比较长的话要选择其他的并发处
理方式，比如信号量和互斥体。

（2）自旋锁保护的临界区内不能调用任何可能导致线程休眠的 API 函数，否则的话可能
导致死锁.

（3）不能递归申请自旋锁，因为一旦通过递归的方式申请一个你正在持有的锁，那么你就
必须“自旋”

三、信号量

相比较自旋锁，信号量可以使线程进入休眠状态，比如 A 与 B、C 合租了一套房子，这个房子只有一个厕所，一次只能一个人使用。某一天早上 A 去上厕所了，过了一会 B 也想用厕所，因为 A 在厕所里面，所以 B 只能等到 A 用来了才能进去。B 要么就一直在厕所门口等着，等 A 出来，这个时候就相当于自旋锁。B 也可以告诉 A，让 A 出来以后通知他一下，然后 B 继续回房间睡觉，这个时候相当于信号量。使用信号量会提高处理器的使用效率，但是，信号量的开销要比自旋锁大，因为信号量使线程进入休眠状态以后会切换线程，切换线程就会有开销。

信号量的特点：

（1）因为信号量可以使等待资源线程进入休眠状态，因此适用于那些占用资源比较久的场
合。
（2）信号量不能用于中断中，因为信号量会引起休眠，中断不能休眠。
（3）如果共享资源的持有时间比较短，那就不适合使用信号量了，因为频繁的休眠、切换线程引起的开销要远大于信号量带来的那点优势。

信号量一般有一个信号量值，可通过信号量值控制方位共享资源的访问数量。例如一个房间有10吧钥匙，相当于信号量值为10，如果想要进入房间，那就需要先获取一把钥匙，信号量值减1，直到10把钥匙都被拿走，信号量为0，此时就不允许人进入房间了，如果有人出来，那么就可以在允许一个人进入。

1
2
3
4
5
struct semaphore {
  raw_spinlock_t lock;
  unsigned int count;
  struct list_head wait_list;
};

信号量的 API 函数：

1
2
3
4
5
struct semaphore sem; /* 定义信号量 */
sema_init(&sem, 1)； /* 初始化信号量 */
down(&sem); /* 申请信号量 */
/* 临界区 */
up(&sem); /* 释放信号量 */

四、互斥体

将信号量的值设置为 1 就可以使用信号量进行互斥访问，但是互斥体有专门的结构体，

1
2
3
4
5
struct mutex {
  /* 1: unlocked, 0: locked, negative: locked, possible waiters */
  atomic_t count;
  spinlock_t wait_lock;
};

特点：
（1）mutex 可以导致休眠，因此不能在中断中使用 mutex，中断中只能使用自旋锁。
（2）和信号量一样，mutex 保护的临界区可以调用引起阻塞的 API 函数。
（3）因为一次只有一个线程可以持有 mutex，因此，必须由 mutex 的持有者释放 mutex。并
且 mutex 不能递归上锁和解锁.

互斥体的接口函数：

1
2
3
4
5
6
struct mutex lock; /* 定义一个互斥体 */
mutex_init(&lock); /* 初始化互斥体 */

mutex_lock(&lock); /* 上锁 */
/* 临界区 */
mutex_unlock(&lock); /* 解锁 */

五、RCU

RCU(Read-Copy Update)，是 Linux 中比较重要的一种同步机制。顾名思义就是“读，拷贝更新”，再直白点是“随意读，但更新数据的时候，需要先复制一份副本，在副本上完成修改，再一次性地替换旧数据”。这是 Linux 内核实现的一种针对“读多写少”的共享数据的同步机制。

适用的场景：
我们前面说过，每种锁都有自己的适用的场景：spin lock不区分reader和writer，对于那些读写强度不对称的是不适合的，RW spin lcok和seq lock解决了这个问题，不过seq lock倾向writer，而RW spin lock更照顾reader。看起来一切都已经很完美了，但是，随着计算机硬件技术的发展，CPU的运算速度越来越快，相比之下，存储器件的速度发展较为滞后。在这种背景下，获取基于counter（需要访问存储器件）的锁（例如spin lock，rwlock）的机制开销比较大。而且，目前的趋势是：CPU和存储器件之间的速度差别在逐渐扩大。因此，那些基于一个multi-processor之间的共享的counter的锁机制已经不能满足性能的需求，在这种情况下，RCU机制应运而生（当然，更准确的说RCU一种内核同步机制，但不是一种lock，本质上它是lock-free的），它克服了其他锁机制的缺点，但是，甘蔗没有两头甜，RCU的使用场景比较受限，主要适用于下面的场景：

（1）RCU只能保护动态分配的数据结构，并且必须是通过指针访问该数据结构

（2）受RCU保护的临界区内不能sleep（SRCU不是本文的内容）

（3）读写不对称，对writer的性能没有特别要求，但是reader性能要求极高。

（4）reader端对新旧数据不敏感。

常用函数为：

1
2
rcu_read_lock();
rcu_read_unlock();
]]> <p>linux并发产生的原因<br>（1）多线程并发访问，<br>（2）抢占式并发访问，进程调度可以在任意时刻抢占正在运行的线程，从而运行其他的线程<br>（3）终端程序并发访问<br>（4）SMP(多核)间并发访问</p> <p>并发访问的后果就是竞争，一般像全局变量，设备结 DTS设备树 http://example.com/posts/DTS%E8%AE%BE%E5%A4%87%E6%A0%91.html 2024-11-25T15:09:20.000Z 2024-11-25T15:09:44.811Z 设备树(Device Tree)，将这个词分开就是“设备”和“树”，描述设备树的文件叫做 DTS(Device Tree Source)，这个 DTS 文件采用树形结构描述板级设备，也就是开发板上的设备信息，比如 CPU 数量、 内存基地址、IIC 接口上接了哪些设备、SPI 接口上接了哪些设备等等

树的主干就是系统总线，IIC 控制器、GPIO 控制器、SPI 控制器等都是接到系统主线上的分支。IIC 控制器有分为 IIC1 和 IIC2 两种，其中 IIC1 上接了 FT5206 和 AT24C02 这两个 IIC 设备，IIC2 上只接了 MPU6050 这个设备。DTS 文件的主要功能就是按照图所示的结构来描述板子上的设备信息，DTS 文件描述设备信息是有相应的语法规则要求的，稍后我们会详细的讲解 DTS 语法规则。

设备树由一系列的节点和属性组成，节点可包含子节点。在设备树中，可描述的信息包括：

  • CPU数量和类型
  • 内存基地址和大小
  • 总线和桥
  • 外设连接
  • 中断控制器和中断使用情况
  • GPIO控制器和GPIO使用情况
  • 时钟控制器和时钟使用情况

bootload 会将这些信息传递给内核，内核开始识别这些树，并解析成 Linux 内核中 platform_device, i2c_client, spi_device等设备，而这些设备使用的内存资源，中断等信息也传递给内核。内核会将这些资源绑定给相应的设备。

一、设备树例子

设备树相关的包含 3 部分：DTS、DTC、DTB

DTS 是设备树源码文件， DTB 是将 DTS 编译以后得到的二进制文件。那么将 .dts 编译为 .dtbn 需要什么工具呢？需要用到 DTC 工具

dts的一个例子如下：
比如 imx6ull.dtsi 就是描述 I.MX6ULL 这颗 SOC 内部外设情况信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "imx6ull-pinfunc.h"
#include "imx6ull-pinfunc-snvs.h"
#include "skeleton.dtsi"
 
/ {
  aliases {
    can0 = &flexcan1;
    ...
  };
  cpus {
    #address-cells = <1>;
    #size-cells = <0>;
 
    cpu0: cpu@0 {
      compatible = "arm,cortex-a7";
      device_type = "cpu";
      reg = <0>;
      clock-latency = <61036>; /* two CLK32 periods */
      operating-points = <
        /* kHzuV */
        9960001275000
        7920001225000
        5280001175000
        3960001025000
        198000950000
      >;
              /* kHzuV */
        9960001275000
        7920001225000
        5280001175000
        3960001025000
      ...
  };
 
  intc: interrupt-controller@00a01000 {
    compatible = "arm,cortex-a7-gic";
    #interrupt-cells = <3>;
    interrupt-controller;
    reg = <0x00a01000 0x1000>,
    <0x00a02000 0x100>;
  };
    ...

文件描述了 CPU arm,cortex-a7 ，支持 996MHz、 792MHz等频率， 时钟一些信息。

“/”是根节点，每个设备树文件只有一个根节点

1
node-name@unit-address

其中 “node-name” 是节点名字，为 ASCII 字符串，节点名字应该能够清晰的描述出节点的功能，比如 “uart1” 就表示这个节点是 UART1 外设。“unit-address” 一般表示设备的地址或寄存器首地址，如果某个节点没有地址或者寄存器的话 “unit-address” 可以不要，比如 “cpu@0”、“interrupt-controller@00a01000”。

1
label: node-name@unit-address

引入 label 的目的就是为了方便访问节点，可以直接通过 &label 来访问这个节点，比如通过&cpu0 就可以访问 “cpu@0” 这个节点。很明显通过 &intc 来访问 “interrupt-controller@00a01000” 这个节点要方便很多！

每个节点都有不同属性，不同的属性又有不同的内容，属性都是键值对，值可以为空或任意的字节流。设备树源码中常用的几种数据形式如下所示：

1、字符串

1
compatible = "fairchild,74hc595";

2、32 位无符号整数

1
reg = <0 0x123456 100>;

3、字符串列表

1
compatible = "fsl,imx6ul-pxp-v4l2", "fsl,imx6sx-pxp-v4l2", "fsl,imx6sl-pxp-v4l2";

二、设备树详解

(1)、标准属性

1、compatible 属性

compatible 属性也叫做“兼容性”属性，这是非常重要的一个属性！ compatible 属性的值是一个字符串列表， compatible 属性用于将设备和驱动绑定起来。字符串列表用于选择设备所要使用的驱动程序，compatible 属性的值格式如下所示：

1
"manufacturer,model"

其中 manufacturer 表示厂商，model 一般是模块对应的驱动名字。比如 imx6ull-alientek-emmc.dts 中 sound 节点是 I.MX6U-ALPHA 开发板的音频设备节点，I.MX6U-ALPHA 开发板上的音频芯片采用的欧胜(WOLFSON)出品的 WM8960，sound 节点的 compatible 属性值如下：

1
compatible = "fsl,imx6ul-evk-wm8960","fsl,imx-audio-wm8960";

其中 “fsl” 表示厂商是飞思卡尔，“imx6ul-evk-wm8960” 和 “imx-audio-wm8960” 表示驱动模块名字。设备首先使用第一个兼容值在 Linux 内核里面查找，如果没有找到的话就使用第二个兼容值查。

2、 model 属性

model 属性值也是一个字符串，一般 model 属性描述设备模块信息，比如名字什么的，比如：

1
model = "wm8960-audio";

3、status 属性

status 属性看名字就知道是和设备状态有关的，status 属性值也是字符串，字符串是设备的状态信息，可选的状态如下表所示：

4、★#address-cells 和#size-cells 属性

#address-cells# 属性值决定了子节点 reg 属性中地址信息所占用的字长(32 位)
#size-cells# 属性值决定了子节点 reg 属性中长度信息所占的字长(32 位)
#address-cells# 和 #size-cells# 表明了子节点应该如何编写 reg 属性值，一般 reg 属性都是和地址有关的内容，和地址相关的信息有两种：起始地址和地址长度， reg 属性的格式一为：

reg = <address1 length1 address2 length2 address3 length3……>

每个 “address length” 组合表示一个地址范围，其中 address 是起始地址， length 是地址长度.
#address-cells# 表明 address 这个数据所占用的字长， #size-cells# 表明 length 这个数据所占用的字长

1
2
3
4
5
6
7
8
9
10
aips3: aips-bus@02200000 {
  compatible = "fsl,aips-bus", "simple-bus";
  #address-cells = <1>;
  #size-cells = <1>;

  dcp: dcp@02280000 {
    compatible = "fsl,imx6sl-dcp";
    reg = <0x02280000 0x4000>;
  };
};

说明 aips3: aips-bus@02200000 节点起始地址长度所占用的字长为 1，地址长度所占用的字长也为 1
子节点 dcp: dcp@02280000 的 reg 属性值为<0x02280000 0x4000>相当于设置了起始地址为 0x02280000，地址长度为 0x40000，但是 dcp的地址长度(范围)并没有 0x4000 这么多

5、 ★reg 属性

reg 属性一般用于描述设备地址空间资源信息，一般都是某个外设的寄存器地址范围信息,一般是(address， length)组成，详情如上所述！

6、ranges 属性

ranges 属性值可以为空或者按照 (child-bus-address,parent-bus-address,length) 格式编写的数字矩阵， ranges 是一个地址映射/转换表， ranges 属性每个项目由子地址、父地址和地址空间长度这三部分组成：

child-bus-address：子总线地址空间的物理地址，由父节点的 #address-cells# 确定此物理地址所占用的字长。
parent-bus-address：父总线地址空间的物理地址，同样由父节点的 #address-cells# 确定此物理地址所占用的字长。
length：子地址空间的长度，由父节点的 #size-cells# 确定此地址长度所占用的字长。

如果 ranges 属性值为空值，说明子地址空间和父地址空间完全相同，不需要进行地址转换，例程如下：

1
2
3
4
5
6
soc {
  #address-cells = <1>;
  #size-cells = <1>;
  compatible = "simple-bus";
  interrupt-parent = <&gpc>;
  ranges;//为空

ranges 属性不为空的示例代码如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
soc {
  compatible = "simple-bus";
  #address-cells = <1>;
  #size-cells = <1>;
  ranges = <0x0 0xe0000000 0x00100000>;

  serial {
    device_type = "serial";
    compatible = "ns16550";
    reg = <0x4600 0x100>;
    clock-frequency = <0>;
    interrupts = <0xA 0x8>;
    interrupt-parent = <&ipic>;
  };
};

节点 soc 定义的 ranges 属性，值为 <0x0 0xe0000000 0x00100000>，此属性值指定了一个 1024KB(0x00100000)的地址范围，子地址空间的物理起始地址为 0x0，父地址空间的物理起始地址为 0xe0000000。

serial 是串口设备节点，reg 属性定义了 serial 设备寄存器的起始地址为 0x4600，寄存器长度为 0x100。经过地址转换，serial 设备可以从 0xe0004600 开始进行读写操作，0xe0004600=0x4600+0xe0000000。

三、向节点追加或修改内容

imx6ull.dtsi 有以下内容，表示 I2C 节点。不同的 I2C 设备有不通的详细属性，采用追加节点方法不会对共有信息带来污染。

1
2
3
4
5
6
7
8
9
i2c1: i2c@021a0000 {
  #address-cells = <1>;
  #size-cells = <0>;
  compatible = "fsl,imx6ul-i2c", "fsl,imx21-i2c";
  reg = <0x021a0000 0x4000>;
  interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
  clocks = <&clks IMX6UL_CLK_I2C1>;
  status = "disabled";
};

现在要在 i2c1 节点下创建一个子节点，这个子节点就是 fxls8471，最简单的方法就是在 i2c1 下直接添加一个名为 fxls8471 的子节点，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
&i2c1 {
  clock-frequency = <100000>;
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_i2c1>;
  status = "okay";

  fxls8471@1e {
    compatible = "fsl,fxls8471";
    reg = <0x1e>;
    position = <0>;
    interrupt-parent = <&gpio5>;
    interrupts = <0 8>;
};

子节点可以修改增加一些属性；
比如子节点中 clock-frequency 新增加的属性。
status 状态由disabled变成 okay

四、设备树在目录中的体现

运行 cd /proc/device-tree 后，ls -a 查询当前目录下的文本情况

1、在当前目录下执行 cat model

model 的内容是 “Freescale i.MX6 ULL 14x14 EVK Board”
compatible 的内容为 “fsl,imx6ull-14x14-evkfsl,imx6ull”

打开文件 imx6ull-alientek-emmc.dts 查看一下，这正是根节点 “/” 的 model 和 compatible 属性值

2、soc子节点

3、aliases 子节点

image

与imx6ull.dtsi中的 aliases一致

4、chosen 子节点

chosen 并不是一个真实的设备， chosen 节点主要是为了 uboot 向 Linux 内核传递数据，重点是 bootargs 参数，一般.dts 文件中 chosen 节点通常为空或者内容很少， imx6ull-alientekemmc.dts 中 chosen 节点内容如下所示：

1
2
3
chosen {
  stdout-path = &uart1;
}

chosen 节点仅仅设置了属性 “stdout-path”，表示标准输出使用 uart1。

1
2
root@ATK-IMX6U:/proc/device-tree/chosen# ls
bootargs  name  stdout-path

我们可以发现 chosen 内存在 boot 的启动参数 bootargs！

cat 查看确实是启动信息
1，我们并没有在设备树中设置 chosen 节点的 bootargs 属性，那么 bootargs这个属性是怎么产生的如何关联起来的呢？
2，为什么和 uboot 中的参数不一致？

chosen 节点的 bootargs 属性不是我们在设备树里面设置的，那么只有一种可能，那就是 uboot 自己在 chosen 节点里面添加了 bootargs 属性，并且设置 bootargs 属性的值为 bootargs环境变量的值。

uboot 源码中搜索 “chosen”，在文件 common/fdt_support.c 中

1
2
3
4
5
6
7
8
9
10
int fdt_chosen(void *fdt)
{
   //寻找chosen节点
  nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");

  if (nodeoffset < 0)
    return nodeoffset;
  //读取bootargs环境
  str = getenv("bootargs");
}

五、Linux 内核解析 DTB 文件

启动内核流程函数

start_kernel 函数中最终调用了函数为 unflatten_dt_node（很多初始化操作都在start_kernel ）！

六、设备树节点的操作函数

Linux 驱动程序往往需要去读取到 Linux 内核中附带的 dts 文件，并操作设备树 DTS 的相关节点！接下来我们来学习一下，如何进行设备树节点操作！

1、查找节点的 of 函数

Linux 内核使用 device_node 结构体来描述一个节点

1、 of_find_node_by_name 函数

1
2
3
4
//通过节点名字查找指定的节点
struct device_node *of_find_node_by_name(struct device_node *from, const char *name);
//from：开始查找的节点，如果为 NULL 表示从根节点开始查找整个设备树。
//name：要查找的节点名字

2、of_find_node_by_type 函数

1
2
//通过device_type查找指定的节点
struct device_node *of_find_node_by_type(struct device_node *from, const char *type)

3、 of_find_compatible_node 函数

1
2
3
4
device_type 和 compatible 这两个属性查找指定的节点
struct device_node *of_find_compatible_node(struct device_node *from,
                      const char *type,
                      const char *compatible)

4、of_find_matching_node_and_match 函数

1
2
3
4
//通过 of_device_id 匹配表来查找指定的节点
struct device_node *of_find_matching_node_and_match(struct device_node *from,
            const struct of_device_id *matches,
            const struct of_device_id **match)

5、of_find_node_by_path 函数

1
2
struct device_node *of_get_parent(const struct device_node *node)
//node 要查找的父节点的节点

七、查找父/子节点的 OF 函数

1、of_get_parent 函数
用于获取指定节点的父节点

1
2
struct device_node *of_get_parent(const struct device_node *node)
//node 要查找的父节点的节点

2、of_get_next_child 函数

1
2
3
4
5
6
//用迭代的查找子节点
struct device_node *of_get_next_child(const struct device_node *node,
                          struct device_node *prev)
//node：父节点。
//prev：前一个子节点，也就是从哪一个子节点开始迭代的查找下一个子//节点。可以设置为NULL，表示从第一个子节点开始。
//返回 找到的下一个子节点。

八、提取属性值的 OF 函数

property 结构体，此结构体定义在文件 include/linux/of.h 中

1
2
3
4
5
6
7
8
9
struct property {
  char *name; /* 属性名字 */
  int length; /* 属性长度 */
  void *value; /* 属性值 */
  struct property *next; /* 下一个属性 */
  unsigned long _flags;
  unsigned int unique_id;
  struct bin_attribute attr;
};

1、 of_find_property 函数

1
2
3
4
5
6
7
property *of_find_property(const struct device_node *np,
               const char *name,
               int *lenp)
//np：设备节点。
//name： 属性名字。
//lenp：属性值的字节数
//返回找到的属性

2、 of_property_count_elems_of_size 函数
用于获取属性中元素的数量，比如 reg 属性值是一个数组，那么使用此函数可以获取到这个数组的大小

1
2
3
4
5
6
7
int of_property_count_elems_of_size(const struct device_node *np,
                      const char *propname,
                      int elem_size)
//np：设备节点。
//proname： 需要统计元素数量的属性名字。
//elem_size：元素长度。
//返回 得到的属性元素数量

3、 of_property_read_u32_index 函数
从属性中获取指定标号的 u32 类型数据值(无符号 32 位)，比如某个属性有多个 u32 类型的值，那么就可以使用此函数来获取指定标号的数据值

1
2
3
4
int of_property_read_u32_index(const struct device_node *np,
                     const char *propname,
                     u32 index,
                     u32 *out_value)

4、of_property_read_u8_array 函数
of_property_read_u16_array 函数
of_property_read_u32_array 函数
of_property_read_u64_array 函数

分别是读取属性中 u8、 u16、 u32 和 u64 类型的数组数据，比如大多数的 reg 属性都是数组数据，可以使用这 4 个函数一次读取出 reg 属性中的所有数据

5、 of_property_read_string 函数

1
2
3
4
//用于读取属性中字符串值
int of_property_read_string(struct device_node *np,
                            const char *propname,
                            const char **out_string)

6、 of_n_addr_cells 函数
用于获取#address-cells 属性值

7、 of_n_size_cells 函数
of_size_cells 函数用于获取#size-cells 属性值

8、of_iomap 函数
采用设备树以后就可以直接通过 of_iomap 函数来获取内存地址所对应的虚拟地址，不需要使用 ioremap 函数了

]]> <p>设备树(Device Tree)，将这个词分开就是“设备”和“树”，描述设备树的文件叫做 DTS(Device Tree Source)，这个 DTS 文件采用树形结构描述板级设备，也就是开发板上的设备信息，比如 CPU 数量、 内存基地址、IIC 接口上接了哪些设备、SP 内核线程 http://example.com/posts/%E5%86%85%E6%A0%B8%E7%BA%BF%E7%A8%8B.html 2024-11-25T15:04:27.000Z 2024-11-25T15:04:48.199Z 一、kthread_create & kthread_run

内核线程是工作在内核空间的，不属于任何一个进程，可以发生睡眠。可以用内核线程来进行一些循环的动作，比如通过循环拉高拉低gpio设置成方波输出的信号来模拟pwm信号，比如循环控制led的闪灯效果等等都可以使用到内核线程kthread_create接口函数。

内核线程的相关代码目录：

1
2
include/linux/kthread.h 
kernel/kthread.c

创建并启动一个内核线程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
struct task_struct *kthread_create(int (*threadfn)(void *data),
                               void *data,
                               const char namefmt[], ...);

_/**_
 _* kthread_run - create and wake a thread._
 _* @threadfn: the function to run until signal_pending(current)._
 _* @data: data ptr for @threadfn._
 _* @namefmt: printf-style name for the thread._
 _*_
 _* Description: Convenient wrapper for kthread_create() followed by_
 _* wake_up_process().  Returns the kthread or ERR_PTR(-ENOMEM)._
 _*/_

#define kthread_run(threadfn, data, namefmt, ...)                        \
({                                                               \
       struct task_struct *__k                                        \
              = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
       if (!IS_ERR(__k))                                        \
              wake_up_process(__k);                                \
       __k;                                                     \
})

其中kthread_create()只是创建一个内核线程，但并没有启动，需要调用wake_up_process()来启动线程，所以内核又帮我们定义了一个宏kthread_run来帮我们搞定。内核线程创建成功后，会返回一个struct task_struct对象指针，方便我们的后续操作。

二、关闭一个内核线程

1
int kthread_stop(struct task_struct *k);

这个调用是会阻塞等待，直到内核线程k退出为止。原因为此函数内部会调用wait_for_completion(）的方法（通过等待队列来实现），阻塞等待内核线程自身的退出。

三、内核线程函数，如何判断自身需要退出

1
int kthread_should_stop(void);

如果该内核线程已经被设置stop标志了，则会返回1，否则返回0。

举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/delay.h>

#define ENTER() printk(KERN_DEBUG "%s() Enter", __func__)
#define EXIT() printk(KERN_DEBUG "%s() Exit", __func__)
#define ERR(fmt, args...) printk(KERN_ERR "%s()-%d: " fmt "\n", __func__, __LINE__, ##args)
#define DBG(fmt, args...) printk(KERN_DEBUG "%s()-%d: " fmt "\n", __func__, __LINE__, ##args)

static struct task_struct *test_kthread = NULL;  //_定义一个_task_struct_结构体指针，赋值为_NULL

static int kthread_test_func(void)   //定义一个内核线程要执行的函数
{
    ENTER();
    while (!kthread_should_stop()) {
        DBG("kthread is running");
        msleep(5000);
    }

    EXIT();
    return 0;

}

static __init int kthread_test_init(void)
{
    ENTER();
    test_kthread = kthread_run(kthread_test_func, NULL, "kthread-test");  _//_创建线程_kthread-test_，并且运行
    if (!test_kthread) {
        ERR("kthread_run fail");
        return -ECHILD;
    }
    EXIT();
    return 0;
}

static __exit void kthread_test_exit(void)
{
    ENTER();
    if (test_kthread) {
        DBG("kthread_stop");
        kthread_stop(test_kthread); _//_停止内核线程
        test_kthread = NULL;
    }
    EXIT();
}

module_init(kthread_test_init);
module_exit(kthread_test_exit);
MODULE_AUTHOR("czd,214241976@qq.com");
MODULE_DESCRIPTION("Device_create Driver");
MODULE_LICENSE("GPL");
]]> <h3 id="一、kthread-create-kthread-run"><a href="#一、kthread-create-kthread-run" class="headerlink" title="一、kthread_create &amp; kthread_run"> 中断下半部-workqueue http://example.com/posts/%E4%B8%AD%E6%96%AD%E4%B8%8B%E5%8D%8A%E9%83%A8-workqueue.html 2024-11-25T15:03:33.000Z 2024-11-25T15:03:51.061Z 工作队列（work queue）是中断下半部的一种实现机制，主要用于耗时任务处理，由内核线程代表进程执行。工作队列运行于进程上下文，因此允许阻塞。

运行工作队列的内核线程，称为工作者线程（worker thread），可以使用系统默认的，也可以自行创建（通常无必要理由不推荐）。

使用工作队列方式：1）初始化工作队列；2）将“工作”（work）放入“工作队列中”。这样，对应的内核线程就会取出“工作”，执行其中的函数。

工作队列缺点：多个工作挤在某个内核线程中依次序执行，前面的函数如果执行得很慢，就会影响到后面的函数。

一、内核数据结构与函数

work queue有关数据结构和函数，都位于<linux/workqueue.h>。

二、work_struct结构体

一个work_struct实例代表一个“工作”，工作包含了用户想要要执行的任务。

work_struct结构体定义：

1
2
3
4
5
6
7
8
9
10
struct work_struct {
    atomic_long_t data;
    struct list_head entry;
    work_func_t func;          // 处理函数
#ifdef CONFIG_LOCKDEP
    struct lockdep_map lockdep_map;
#endif
};

typedef void (*work_func_t)(struct work_struct *work);

使用work queue时，步骤如下：
1）构造一个work_struct实例，设置处理函数。
2）把work_struct放入工作队列，内核线程会运行work中的函数（func）。

三、使用work queue

创建work

静态创建

宏DECLARE_WORK用来定义一个work_struct结构体，需要指定它的处理函数。
宏DECLARE_DELAYED_WORK用来定义一个delayed_work结构体，也需要指定它的处理函数。“delayed”指延时，意思是要让该“工作”运行时，可以通过该宏指定延时的时间。

1
2
3
4
5
#define DECLARE_WORK(n, f)                        \
    struct work_struct n = __WORK_INITIALIZER(n, f)

#define DECLARE_DELAYED_WORK(n, f)                    \
    struct delayed_work n = __DELAYED_WORK_INITIALIZER(n, f, 0)

delayed_work结构体，其实是一个work_struct和一个timer_list等成员的复合结构。

1
2
3
4
5
6
7
8
struct delayed_work {
    struct work_struct work; // 工作队列的工作
    struct timer_list timer; // 超时时间

    /* target workqueue and CPU ->timer uses to queue ->work */
    struct workqueue_struct *wq;
    int cpu;
};
动态创建

宏INIT_WORK用来初始化work_struct结构体：

1
2
#define INIT_WORK(_work, _func)                        \
    __INIT_WORK((_work), (_func), 0)

四、创建工作队列

Linux系统中已有现成的system_wq等工作队列，使用工作队列时，通常推荐用现成的。

1
2
3
4
5
6
7
8
9
// Linux中现成的工作队列

extern struct workqueue_struct *system_wq;
extern struct workqueue_struct *system_highpri_wq;
extern struct workqueue_struct *system_long_wq;
extern struct workqueue_struct *system_unbound_wq;
extern struct workqueue_struct *system_freezable_wq;
extern struct workqueue_struct *system_power_efficient_wq;
extern struct workqueue_struct *system_freezable_power_efficient_wq;

如果需要自行创建，也有办法，可以使用create_workqueue或create_singlethread_workqueue。
create_workqueue会在SMP系统中，针对每个CPU，都创建一个内核线程和创建的工作队列对应。
create_singlethread_workqueue 只会有一个内核线程与工作队列对应。

五、销毁工作队列

与创建工作队列相对的，是销毁工作队列，可以调用destroy_workqueue来执行该操作。

1
void destroy_workqueue(struct workqueue_struct *wq);

六、调度执行work

schedule_work调度执行一个具体的work，执行的work将会被挂入Linux提供的（默认system_wq）工作队列。

1
static inline bool schedule_work(struct work_struct *work);

如果想延迟执行work，可以调用schedule_delayed_work ，其功能类似于schedule_work，不过多了一个延迟。

1
2
static inline bool schedule_delayed_work(struct delayed_work *dwork,
                     unsigned long delay);

queue_work 跟schedule_work类似，区别在于schedule_work是在系统默认的工作队列上执行一个work，而queue_work 需要自行指定工作队列。

其实，schedule_work是利用queue_work实现的，例如系统默认的工作队列system_wq：

1
2
3
4
static inline bool schedule_work(struct work_struct *work)
{
    return queue_work(system_wq, work);
}

queue_delayed_work 跟schedule_delayed_work 类似，区别在于schedule_delayed_work 是在系统默认的工作队列上执行一个work，queue_delayed_work需要自行指定工作队列。类似地，schedule_delayed_work也是依赖于queue_delayed_work实现的。

1
2
3
4
5
static inline bool schedule_delayed_work(struct delayed_work *dwork,
                     unsigned long delay)
{
    return queue_delayed_work(system_wq, dwork, delay);
}

七、等待work

flush_work 等待一个work执行完毕。如果该work已经被放入队列，那么本函数等它执行完毕，并且返回true；如果该work已经执行完毕才调用本函数，那么直接返回false。

1
bool flush_work(struct work_struct *work);

flush_delayed_work 等待一个delayed_work执行完毕。如果这个delayed_work已经被放入队列，那么本函数等它执行完毕，并且返回true；如果这个delayed_work已经执行完毕才调用本函数，那么直接返回false。

1
bool flush_delayed_work(struct delayed_work *dwork);

TIPS：前面提到过，delayed_work是一个复合了work_struct，timer_list等成员的结构体。

八、等待work queue

flush_work是等待一个work执行完毕，而flush_workqueue是等待一个工作队列上所有work执行完毕。

1
void flush_workqueue(struct workqueue_struct *wq)

九、work queue的内部机制

Linux内核2.x 版本中，创建workqueue时会同步创建内核线程；
Linux内核4.x 版本中，内核线程和workqueue分开创建，较为复杂。

Linux 2.x的工作队列创建过程

kernel/workqueue：

1
2
3
4
5
6
init_workqueues
keventd_wq = create_workqueue("events"); // 创建名为"events"的工作队列
    __create_workqueue((name), 0, 0)
        for_each_possible_cpu(cpu) {
            err = create_workqueue_thread(cwq, cpu); // 创建用于工作队列的内核线程
                    p = kthread_create(worker_thread, cwq, fmt, wq->name, cpu); // 创建内核线程

对于每个CPU，都创建一个名为“events/n”的内核线程，n是处理器编号，从0开始。

创建workqueue的同时，创建内核线程。

每个CPU上都有一个cpu_workqueue_struct，而每个cpu_workqueue_struct下只有1个线程用于work queue执行work。所有内核线程可以从同一个work queue取work。

Linux 4.x的工作队列创建过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
init_workqueues
/* initialize CPU pools */
for_each_possible_cpu(cpu) {
    for_each_cpu_worker_pool(pool, cpu) {
         /* 对每一个CPU都创建2个worker_pool结构体，它是含有ID的 */
         /*  一个worker_pool对应普通优先级的work，第2个对应高优先级的work */
}

/* create the initial worker */
for_each_online_cpu(cpu) {
    for_each_cpu_worker_pool(pool, cpu) {
        /* 对每一个CPU的每一个worker_pool，创建一个worker */
/* 每一个worker对应一个内核线程 */
        BUG_ON(!create_worker(pool));
    }
}

create_worker：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
static struct worker *create_worker(struct worker_pool *pool)
{
    struct worker *worker = NULL;
    int id = -1;
    char id_buf[16];

    /* ID is needed to determine kthread name */
    id = ida_simple_get(&pool->worker_ida, 0, 0, GFP_KERNEL);
    if (id < 0)
        goto fail;

    worker = alloc_worker(pool->node);
    if (!worker)
        goto fail;

    worker->pool = pool;
    worker->id = id;
  
    if (pool->cpu >= 0)
        snprintf(id_buf, sizeof(id_buf), "%d:%d%s", pool->cpu, // 在哪个CPU上运行
             id, // poll中第几个线程
             pool->attrs->nice < 0  ? "H" : "");  // H: 高优先级
    else
        snprintf(id_buf, sizeof(id_buf), "u%d:%d", pool->id, id);

    worker->task = kthread_create_on_node(worker_thread, worker, pool->node,
                          "kworker/%s", id_buf); // 内核线程的名字
    ...
}

创建号内核线程（”kworker/n:id”）后，再创建workqueue

1
2
3
4
5
init_workqueues
    system_wq = alloc_workqueue("events", 0, 0);
        __alloc_workqueue_key
            wq = kzalloc(sizeof(*wq) + tbl_size, GFP_KERNEL); // 分配workqueue_struct
            alloc_and_link_pwqs(wq)  // 跟worker_poll建立联系

每个CPU对应2个woker_pool：一个普通的worker_pool，一个高优先级的worker_pool。每个线程池包含多个内核线程，用于执行同一个worker queue的work。work_pool的线程名，形如”kworker/n:idH”，n代表CPU编号，id是子线程编号，H代表高优先级，如果普通优先级则为空。

对于CPU 0：
普通worker_pool线程名，形如”kworker/0:0”，”kworker/0:1”，”kworker/0:2”。:
高优先级的worker_pool线程名，形如”kworker/0:0H”，”kworker/0:1H”，”kworker/0:2H”。

]]> <p>工作队列（work queue）是中断下半部的一种实现机制，主要用于耗时任务处理，由内核线程代表进程执行。工作队列运行于进程上下文，因此允许阻塞。</p> <p>运行工作队列的内核线程，称为工作者线程（worker thread），可以使用系统默认的，也可以自行创建（通常无 中断下半部-tasklet http://example.com/posts/%E4%B8%AD%E6%96%AD%E4%B8%8B%E5%8D%8A%E9%83%A8-tasklet.html 2024-11-25T15:02:32.000Z 2024-11-25T15:03:00.857Z tasklet 是中断下半部的一种实现机制，主要用于小任务处理，耗时较短、不能阻塞的任务，用tasklet处理较合适。对于耗时较长，可以用work queue（工作队列）来处理。

tasklet和内核定时器timer_list都是通过软中断方式来实现的。

一、tasklet结构体

中断下半部用结构体tasklet_struct来表示

1
2
3
4
5
6
7
8
9
10
#include <linux/interrupt.h>

struct tasklet_struct
{
    struct tasklet_struct *next;
    unsigned long state;
    atomic_t count;
    void (*func)(unsigned long);
    unsigned long data;
};

其中，state有2位：
1）bit0：表示TASKLET_STATE_SCHED
等于1，表示已经执行了tasklet_schedule，该把tasklet放入队列了。tasklet_schedule会判断该位，如果已经等于1，那么它就不会再次把tasklet放入队列。

2）bit1：表示TASKLET_STATE_RUN
等于1，表示正在运行tasklet中的func函数。函数执行完毕后，内核会把该位清0。

count表示该tasklet是否使能：值0表示使能了，非0表示被禁止了。对于count非0的tasklet，func()不会被执行。

data 是传递给func()的参数。

二、初始化tasklet_strcut

静态初始化：

宏初始化tasklet_struct

1
2
3
4
5
#define DECLARE_TASKLET(name, func, data) \
struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data };

#define DECLARE_TASKLET_DISABLED(name, func, data) \
struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data };

使用DECLARE_TASKLET定义的tasklet结构体，它是使能的。
使用DECLARE_TASKLET_DISABLED定义的tasklet结构体，它是禁止的。使用之前要先调用tasklet_enable使能之。

动态初始化：

也可用函数tasklet_init()初始化tasklet结构体：
data是func的参数

1
2
tasklet_init(struct tasklet_struct *t,
             void (*func)(unsigned long), unsigned long data);

三、使能/禁止tasklet

tasklet_enable将count加1；tasklet_disable将count减1。

1
2
3
static inline void tasklet_enable(struct tasklet_struct *t);  // 使能

static inline void tasklet_disable(struct tasklet_struct *t); // 禁止

四、调度tasklet

将tasklet放入链表，并设置它的TASKLET_STATE_SCHED状态为1。

1
static inline void tasklet_schedule(struct tasklet_struct *t);

五、kill tasklet

从链表中删除tasklet。如果一个tasklet未被调度，tasklet_kill会将它的TASKLET_STATE_SCHED状态清0；如果一个tasklet已被调度，tasklet_kill会等待它执行完毕，再把它的TASKLET_STATE_SCHED状态清0。
通常，在卸载驱动程序（module_exit）时，调用task_kill。

tasklet_kill_immediate 与tasklet_kill区别是，前者会立即移除tasklet，二不论tasklet是否处于TASKLET_STATE_SCHED状态。

1
2
3
void tasklet_kill(struct tasklet_struct *t); // 移除tasklet

void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu); // 立即移除tasklet

六、tasklet使用方法

先定义tasklet实例，需要使用时调用tasklet_schedule，驱动卸载前调用tasklet_kill。tasklet_schedule只是将tasklet放入内核队列，其func函数会在软中断执行过程中被调用。

七、tasklet内部实现机制

前面讲过，tasklet是通过软中断实现，属于TASKLET_SOFTIRQ类型的软中断。入口函数tasklet_action。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// kernel/softirq.c

void __init softirq_init(void)
{
    int cpu;

    for_each_possible_cpu(cpu) {
        per_cpu(tasklet_vec, cpu).tail =
            &per_cpu(tasklet_vec, cpu).head;
        per_cpu(tasklet_hi_vec, cpu).tail =
            &per_cpu(tasklet_hi_vec, cpu).head;
    }

    open_softirq(TASKLET_SOFTIRQ, tasklet_action); // 注册TASKLET_SOFTIRQ类型软中断(普通软中断)及其处理函数
    open_softirq(HI_SOFTIRQ, tasklet_hi_action);   // 高优先级软中断
}

在软中断的初始化（softirq_init）末尾，通过open_softirq注册TASKLET_SOFTIRQ类型的软中断（即tasklet）及其处理函数（即tasklet_action）。

驱动程序调用tasklet_schedule时，会设置tasket的state为TASKLET_STATE_SCHED，并把它放入某个链表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
static inline void tasklet_schedule(struct tasklet_struct *t)
{
    // 1. 如果未设置为SCHED，则设置为SCHED并放入队列
    if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) // 设置tasklet.state为TASKLET_STATE_SCHED
        __tasklet_schedule(t);
}

void __tasklet_schedule(struct tasklet_struct *t)
{
    unsigned long flags;

    local_irq_save(flags); // 保存中断
    // 2. 放入队列
    t->next = NULL;
    *__this_cpu_read(tasklet_vec.tail) = t;
    __this_cpu_write(tasklet_vec.tail, &(t->next));
    raise_softirq_irqoff(TASKLET_SOFTIRQ); // 唤醒中断, 会导致调用该类型软中断对应的处理函数
    local_irq_restore(flags); // 恢复中断到flags状态
}
EXPORT_SYMBOL(__tasklet_schedule);

产生硬件中断时，讹你好处理完硬件中断后，会处理软中断。对于TASKLET_SOFTIRQ软中断，会调用tasklet_action函数。

执行过程是：从队列中找到tasklet，进行状态判断后执行func函数，从队列中删除tasklet。
可知：
1）tasklet_schedule 调度tasklet时，其中的函数并不会立即执行，而只是把tasklet放入队列；
2）调用一次tasklet_schedule，只会导致tasklet的函数被执行一次；
3）如果tasklet的函数尚未执行，多次调用tasklet_schedule也是少的，只会放入队列一次。

普通软中断处理函数tasklet_action：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
static __latent_entropy void tasklet_action(struct softirq_action *a)
{
    struct tasklet_struct *list;

    local_irq_disable();
    list = __this_cpu_read(tasklet_vec.head);
    __this_cpu_write(tasklet_vec.head, NULL);
    __this_cpu_write(tasklet_vec.tail, this_cpu_ptr(&tasklet_vec.head));
    local_irq_enable();

    while (list) {
        struct tasklet_struct *t = list;

        list = list->next; // 1. 从列表中去除每一项

        if (tasklet_trylock(t)) {
            if (!atomic_read(&t->count)) {
                // 2. 判断：如果不是SCHED状态，就是有BUG
                if (!test_and_clear_bit(TASKLET_STATE_SCHED,
                            &t->state))
                    BUG();
                t->func(t->data); // 3. 执行tasklet的func
                tasklet_unlock(t);
                continue;
            }
            tasklet_unlock(t);
        }

        local_irq_disable();
        // 4. 从队列中取出
        t->next = NULL;
        *__this_cpu_read(tasklet_vec.tail) = t;
        __this_cpu_write(tasklet_vec.tail, &(t->next));

        __raise_softirq_irqoff(TASKLET_SOFTIRQ);
        local_irq_enable();
    }
}
]]> <p>tasklet 是中断下半部的一种实现机制，主要用于小任务处理，耗时较短、不能阻塞的任务，用tasklet处理较合适。对于耗时较长，可以用work queue（工作队列）来处理。</p> <p>tasklet和内核定时器timer_list都是通过软中断方式来实现的。</p