1. 前言
2 为何需要workqueue
- 2.1 什么是中断上下文和进程上下文？
- 2.2 如何判定当前的context？
- 2.3 为何中断上下文不能sleep？
- 2.4 为何需要workqueue
3 数据抽象
- 3.1 workqueue
- 3.2 work
- 3.3 总结
4 接口以及内部实现
- 4.1 初始化一个work
- 4.2 调度一个work执行
- 4.3 创建workqueue
- 4.4 work执行的时机

1. 前言

workqueue是一个驱动工程师常用的工具，在旧的内核中（指2.6.36之前的内核版本）workqueue代码比较简单（大概800行），在2.6.36内核版本中引入了CMWQ（Concurrency Managed Workqueue），workqueue.c的代码膨胀到5000多行，为了深入的理解CMWQ，单单一份文档很难将其描述的清楚，因此CMWQ作为一个主题将会产生一系列的文档，本文是这一系列文档中的第一篇，主要是基于2.6.23内核的代码实现来讲述workqueue的一些基本概念（之所以选择较低版本的内核，主要是因为代码简单，适合理解基本概念）。

2 为何需要workqueue

2.1 什么是中断上下文和进程上下文？

在继续描述workqueue之前，我们先梳理一下中断上下文和进程上下文。

对于中断上下文，主要包括两种情况：

（1）执行该中断的处理函数（我们一般称之interrupt handler或者叫做top half），也就是hard interrupt context

（2）执行软中断处理函数，执行tasklet函数，执行timer callback函数。（或者统称bottom half），也就是software interrupt context。

top half当然是绝对的interrupt context，但对于上面的第二种情况，稍微有些复杂，其执行的现场包括：

（1）执行完top half，立刻启动bottom half的执行

（2）当负荷比较重的时候（中断产生的比较多），系统在一段时间内都在处理interrupt handler以及相关的softirq，从而导致无法调度到进程执行，这时候，linux kernel采用了将softirq推迟到softirqd这个内核线程中执行

（3）进程在内核态运行的时候，由于内核同步的需求，需要使用local_bh_disable/local_bh_enable来保护临界区。在临界区代码执行的时候，有可能中断触发并raise softirq，但是由于softirq处于disable状态从而在中断返回的时候没有办法invoke softirq的执行，当调用local_bh_enable的时候，会调用已经触发的那个softirq handler。

对于上面的情况1和情况3，毫无疑问，绝对的中断上下文，执行现场的current task和softirq handler没有任何的关系。对于情况2，虽然是在专属的内核线程中执行，但是我也倾向将其归入software interrupt context。

对于linux而言，中断上下文都是惊鸿一瞥，只有进程（线程、或者叫做task）是永恒的。整个kernel都是在各种进程中切来切去，一会儿运行在进程的用户空间，一会儿通过系统调用进入内核空间。当然，系统不是封闭的，还是需要通过外设和User或者其他的系统进行交互，这里就需要中断上下文了，在中断上下文中，完成硬件的交互，最终把数据交付进程或者进程将数据传递给外设。进程上下文有丰富的、属于自己的资源：例如有硬件上下文，有用户栈、有内核栈，有用户空间的正文段、数据段等等。而中断上下文什么也没有，只有一段执行代码及其附属的数据。那么问题来了：中断执行thread中的临时变量应该保存在栈上，那么中断上下文的栈在哪里？中断上下文没有属于自己的栈，肿么办？那么只能借了，当中断发生的时候，遇到哪一个进程就借用哪一个进程的资源（遇到就是缘分呐）。

2.2 如何判定当前的context？

OK，上一节描述中断上下文和进程上下文的含义，那么代码如何知道自己的上下文呢？下面我们结合代码来进一步分析。in_irq()是用来判断是否在hard interrupt context的，我们一起来来看看in_irq()是如何定义的：

#define in_irq()        (hardirq_count())
#define hardirq_count()    (preempt_count() & HARDIRQ_MASK)

top half的处理是被irq_enter()和irq_exit()所包围，在irq_enter函数中会调用preempt_count_add(HARDIRQ_OFFSET)，为hardirq count的bit field增加1。在irq_exit函数中，会调用preempt_count_sub(HARDIRQ_OFFSET)，为hardirq count的bit field减去1。因此，只要in_irq非零，则说明在中断上下文并且处于top half部分。

解决了hard interrupt context，我们来看software interrupt context。如何判定代码当前正在执行bottom half（softirq、tasklet、timer）呢？in_serving_softirq给出了答案：

#define in_serving_softirq()    (softirq_count() & SOFTIRQ_OFFSET)

需要注意的是：在2.6.23内核中没有这个定义（上面的代码来自4.0的内核）。内核中还有一个类似的定义：

#define in_softirq()        (softirq_count())
#define softirq_count()    (preempt_count() & SOFTIRQ_MASK)

in_softirq定义了更大的一个区域，不仅仅包括了in_serving_softirq上下文，还包括了disable bottom half的场景。我们用下面一个图片来描述：

config

我们知道，在进程上下文中，由于内核同步的要求可能会禁止softirq。这时候，kernel提供了local_bf_enable和local_bf_disable这样的接口函数，这种场景下，在local_bf_enable函数中会执行软中断handler（在临界区中，虽然raise了softirq，但是由于disable了bottom half，因此无法执行，只有等到enable的时候第一时间执行该softirq handler）。in_softirq包括了进程上下文中disable bottom half的临界区部分，而in_serving_softirq精准的命中了software interrupt context。

内核中还有一个in_interrupt的宏定义，从它的名字上看似乎是定义了hard interrupt context和software interrupt context，到底是怎样的呢？我们来看看定义：

#define in_interrupt()        (irq_count()) 
#define irq_count()    (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \ | NMI_MASK))

注：上面的代码来自4.0的内核。HARDIRQ_MASK定义了hard interrupt contxt，NMI_MASK定义了NMI（对于ARM是FIQ）类型的hard interrupt context，SOFTIRQ_MASK包括software interrupt context加上禁止softirq情况下的进程上下文。因此，in_interrupt()除了包括了中断上下文的场景，还包括了进程上下文禁止softirq的场景。

还有一个in_atomic的宏定义，大家可以自行学习，这里不再描述了。

2.3 为何中断上下文不能sleep？

linux驱动工程师应该都会听说过这句话：中断上下文不能sleep，但是为什么呢？这个问题可以仔细思考一下。所谓sleep就是调度器挂起当前的task，然后在run queue中选择另外一个合适的task运行。规则很简单，不过实际操作就没有那么容易了。有一次，我们调试wifi驱动的时候，有一个issue很有意思：正常工作的时候一切都是OK的，但是当进行压力测试的时候，系统就会down掉。最后发现是在timer的callback函数中辗转多次调用了kmalloc函数，我们都知道，在某些情况下，kmalloc会导致当前进程被block。

从操作系统设计的角度来看，大部分的OS都规定中断上下文不能sleep，有些是例外的，比如solaris，每个中断的handler都是在它自己的task中处理的，因此可以在中断handler中sleep。不过在这样的系统中（很多RTOS也是如此处理的），实际的中断上下文非常的薄，可能就是向该中断handler对应的task发送一个message，所有的处理（ack中断、mask中断、copy FIFO等）都是在该中断的task中处理。这样的系统中，当然可以在中断handler中sleep，不过这有点偷换概念，毕竟这时候的上下文不是interrupt context，更准确的说是中断处理的process context，这样的系统interrupt context非常非常的简单，几乎没有。

当然，linux的设计并非如此（其实在rt linux中已经有了这样的苗头，可以参考中断线程化的文章），中断handler以及bottom half（不包括workqueue）都是在interrupt context中执行。当然一提到context，各种资源还是要存在的，例如说内核栈、例如说memory space等，interrupt context虽然单薄，但是可以借尸还魂。当中断产生的那一个时刻，当前进程有幸成为interrupt context的壳，提供了内核栈，保存了hardware context，此外各种资源（例如mm_struct）也是借用当前进程的。本来呢interrupt context身轻如燕，没有依赖的task，调度器其实是不知道如何调度interrupt context的（它处理的都是task），在interrupt context借了一个外壳后，从理论上将，调度器是完全可以block该interrupt context执行，并将其他的task调入进入running状态。然而，block该interrupt context执行也就block其外壳task的执行，多么的不公平，多么的不确定，中断命中你，你就活该被schedule out，拥有正常思维的linux应该不会这么做的。

因此，在中断上下文中（包括hard interrupt context和software interrupt context）不能睡眠。

2.4 为何需要workqueue

workqueue和其他的bottom half最大的不同是它是运行在进程上下文中的，它可以睡眠，这和其他bottom half机制有本质的不同，大大方便了驱动工程师撰写中断处理代码。当然，驱动模块也可以自己创建一个kernel thread来解决defering work，但是，如果每个driver都创建自己的kernel thread，那么内核线程数量过多，这会影响整体的性能。因此，最好的方法就是把这些需求汇集起来，提供一个统一的机制，也就是传说中的work queue了。

3 数据抽象

3.1 workqueue

定义如下：

struct workqueue_struct { struct cpu_workqueue_struct *cpu_wq; －－－－－per-cpu work queue struct struct list_head list; －－－workqueue list const char *name; int singlethread; －－－－single thread or multi thread int freezeable;  －－－－和电源管理相关的一个flag 
};

我们知道，workqueue就是一种把某些任务（work）推迟到一个或者一组内核线程中去执行，那个内核线程被称作worker thread（每个processor上有一个work thread）。系统中所有的workqueue会挂入一个全局链表，链表头定义如下：

static LIST_HEAD(workqueues);

list成员就是用来挂入workqueue链表的。singlethread是workqueue的一个特殊模式，一般而言，当创建一个workqueue的时候会为每一个系统内的processor创建一个内核线程，该线程处理本cpu调度的work。但是有些场景中，创建per-cpu的worker thread有些浪费（或者有一些其他特殊的考量），这时候创建single-threaded workqueue是一个更合适的选择。freezeable成员是一个和电源管理相关的一个flag，当系统suspend的时候，有一个阶段会将所有的用户空间的进程冻结，那么是否也冻结内核线程（包括workqueue）呢？缺省情况下，所有的内核线程都是nofrezable的，当然也可以调用set_freezable让一个内核线程是可以被冻结的。具体是否需要设定该flag是和程序逻辑相关的，具体情况具体分析。OK，上面描述的都是workqueue中各个processor共享的成员，下面我们看看per-cpu的数据结构：

struct cpu_workqueue_struct {spinlock_t lock; －－－－用来保护worklist资源的访问struct list_head worklist; wait_queue_head_t more_work; －－－－－等待队列头 struct work_struct *current_work; －－－－当前正在处理的workstruct workqueue_struct *wq; －－－－－－指向work queue struct struct task_struct *thread; －－－－－－－worker thread taskint run_depth;        /* Detect run_workqueue() recursion depth */ 
} ____cacheline_aligned;

worker thread要处理work，这些work被挂入work queue中的链表结构。由于每个processor都需要处理自己的work，因此这个work list是per cpu的。worklist成员就是这个per cpu的链表头，当worker thread被调度到的时候，就从这个队列中一个个的摘下work来处理。

3.2 work

定义如下：

struct work_struct { atomic_long_t data; struct list_head entry; work_func_t func; 
};

所谓work就是异步执行的函数。你可能会觉得，反正是函数，直接调用不就OK了吗？但是，事情没有那么简单，如果该函数的代码中有些需要sleep的场景的时候，那么在中断上下文中直接调用将产生严重的问题。这时候，就需要到进程上下文中异步执行。下面我们仔细看看各个成员：func就是这个异步执行的函数，当work被调度执行的时候其实就是调用func这个callback函数，该函数的定义如下：

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

work对应的callback函数需要传递该work的struct作为callback函数的参数。work是被组织成队列的，entry成员就是挂入队列的那个节点，data包含了该work的状态flag和挂入workqueue的信息。

3.3 总结

我们把上文中描述的各个数据结构集合在一起，具体请参考下图：

config

我们自上而下来描述各个数据结构。首先，系统中包括若干的workqueue，最著名的workqueue就是系统缺省的的workqueue了，定义如下：

static struct workqueue_struct *keventd_wq __read_mostly;

如果没有特别的性能需求，那么一般驱动使用keventd_wq就OK了，毕竟系统创建太多内核线程也不是什么好事情（消耗太多资源）。当然，如果有需要，驱动模块可以创建自己的workqueue。因此，系统中存在一个workqueues的链表，管理了所有的workqueue实例。一个workqueue对应一组work thread（先不考虑single thread的场景），每个cpu一个，由cpu_workqueue_struct来抽象，这些cpu_workqueue_struct们共享一个workqueue，毕竟这些worker thread是同一种type。

从底层驱动的角度来看，我们只关心如何处理deferable task（由work_struct抽象）。驱动程序定义了work_struct，其func成员就是deferred work，然后挂入work list就OK了（当然要唤醒worker thread了），系统的调度器调度到worker thread的时候，该work自然会被处理了。当然，挂入哪一个workqueue的那一个worker thread呢？如何选择workqueue是driver自己的事情，可以使用系统缺省的workqueue，简单，实用。当然也可以自己创建一个workqueue，并把work挂入其中。选择哪一个worker thread比较简单：work在哪一个cpu上被调度，那么就挂入哪一个worker thread。

4 接口以及内部实现

4.1 初始化一个work

我们可以静态定义一个work，接口如下：

#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)

一般而言，work都是推迟到worker thread被调度的时刻，但是有时候，我们希望在指定的时间过去之后再调度worker thread来处理该work，这种类型的work被称作delayed work，DECLARE_DELAYED_WORK用来初始化delayed work，它的概念和普通work类似，本文不再描述。

动态创建也是OK的，不过初始化的时候需要把work的指针传递给INIT_WORK，定义如下：

#define INIT_WORK(_work, _func)                        \ do {                                \ (_work)->data = (atomic_long_t) WORK_DATA_INIT();    \ INIT_LIST_HEAD(&(_work)->entry);            \ PREPARE_WORK((_work), (_func));                \ } while (0)

4.2 调度一个work执行

调度work执行有两个接口，一个是schedule_work，将work挂入缺省的系统workqueue（keventd_wq），另外一个是queue_work，可以将work挂入指定的workqueue。具体代码如下：

int fastcall queue_work(struct workqueue_struct *wq, struct work_struct *work) 
{ int ret = 0;if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) { __queue_work(wq_per_cpu(wq, get_cpu()), work);－－－挂入work list并唤醒worker thread put_cpu(); ret = 1; } return ret; 
}

处于pending状态的work不会重复挂入workqueue。我们假设A驱动模块静态定义了一个work，当中断到来并分发给cpu0的时候，中断handler会在cpu0上执行，我们在handler中会调用schedule_work将该work挂入cpu0的worker thread，也就是keventd 0的work list。在worker thread处理A驱动的work之前，中断很可能再次触发并分发给cpu1执行，这时候，在cpu1上执行的handler在调用schedule_work的时候实际上是没有任何具体的动作的，也就是说该work不会挂入keventd 1的work list，因为该work还pending在keventd 0的work list中。

到底插入workqueue的哪一个worker thread呢？这是由wq_per_cpu定义的：

static struct cpu_workqueue_struct *wq_per_cpu(struct workqueue_struct *wq, int cpu) 
{ if (unlikely(is_single_threaded(wq))) cpu = singlethread_cpu; return per_cpu_ptr(wq->cpu_wq, cpu); 
}

普通情况下，都是根据当前的cpu id，通过per_cpu_ptr获取cpu_workqueue_struct的数据结构，对于single thread而言，cpu是固定的。

4.3 创建workqueue

接口如下：

#define create_workqueue(name) __create_workqueue((name), 0, 0) 
#define create_freezeable_workqueue(name) __create_workqueue((name), 1, 1) 
#define create_singlethread_workqueue(name) __create_workqueue((name), 1, 0)

create_workqueue是创建普通workqueue，也就是每个cpu创建一个worker thread的那种。当然，作为“普通”的workqueue，在freezeable属性上也是跟随缺省的行为，即在suspend的时候不冻结该内核线程的worker thread。create_freezeable_workqueue和create_singlethread_workqueue都是创建single thread workqueue，只不过一个是freezeable的，另外一个是non-freezeable的。的代码如下：

struct workqueue_struct *__create_workqueue(const char *name, int singlethread, int freezeable) 
{ struct workqueue_struct *wq; struct cpu_workqueue_struct *cwq; int err = 0, cpu;wq = kzalloc(sizeof(*wq), GFP_KERNEL);－－－－分配workqueue的数据结构wq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct);－－－分配worker thread的数据结构wq->name = name;－－－－－－－－－－初始化workqueue wq->singlethread = singlethread; wq->freezeable = freezeable; INIT_LIST_HEAD(&wq->list);if (singlethread) {－－－－－－－－－－－－－－－－－－－－－－－（1） cwq = init_cpu_workqueue(wq, singlethread_cpu); －－－初始化cpu_workqueue_struct err = create_workqueue_thread(cwq, singlethread_cpu); －－－创建worker thread start_workqueue_thread(cwq, -1); －－－－wakeup worker thread } else { －－－－－－－－－－－－－－－－－－－－－－－－－－－－－（2） mutex_lock(&workqueue_mutex); list_add(&wq->list, &workqueues);for_each_possible_cpu(cpu) { cwq = init_cpu_workqueue(wq, cpu); if (err || !cpu_online(cpu)) －－－－没有online的cpu就不需要创建worker thread了 continue; err = create_workqueue_thread(cwq, cpu); start_workqueue_thread(cwq, cpu); } mutex_unlock(&workqueue_mutex); }  return wq; 
}

（1）不管是否是single thread workqueue，worker thread（cpu_workqueue_struct）的数据结构总是per cpu分配的（稍显浪费），不过实际上对于single thread workqueue而言，只会使用其中之一，那么问题来了：使用哪一个processor的cpu_workqueue_struct呢？workqueue代码定义了一个singlethread_cpu的变量，如下：

static int singlethread_cpu __read_mostly;

该变量会在init_workqueues函数中进行初始化。实际上，使用哪一个cpu的cpu_workqueue_struct是无所谓的，选择其一就OK了。由于是single thread workqueue，因此创建的worker thread并不绑定在任何的cpu上，调度器可以自由的调度该内核线程在任何的cpu上运行。

（2）对于普通的workqueue，和single thread的处理有所有不同。一方面，single thread的workqueue没有挂入workqueues的全局链表，另外一方面for_each_possible_cpu确保在每一个cpu上创建了一个worker thread并通过start_workqueue_thread启动其运行，具体代码如下：

static void start_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu) 
{ struct task_struct *p = cwq->thread;if (p != NULL) { if (cpu >= 0) kthread_bind(p, cpu); wake_up_process(p); } 
}

对于single thread，kthread_bind不会执行，对于普通的workqueue，我们必须调用kthread_bind以便让worker thread在特定的cpu上执行。

4.4 work执行的时机

work执行的时机是和调度器相关的，当系统调度到worker thread这个内核线程后，该thread就会开始工作。每个cpu上执行的worker thread的内核线程的代码逻辑都是一样的，在worker_thread中实现：

static int worker_thread(void *__cwq) 
{ struct cpu_workqueue_struct *cwq = __cwq; DEFINE_WAIT(wait);if (cwq->wq->freezeable)－－－如果是freezeable的内核线程，那么需要清除task flag中的 set_freezable();                    PF_NOFREEZE标记，以便在系统suspend的时候冻结该threadset_user_nice(current, -5); －－－－提高进程优先级，呵呵，worker thread还是有些特权的哦for (;;) { prepare_to_wait(&cwq->more_work, &wait, TASK_INTERRUPTIBLE); if (!freezing(current) &&  !kthread_should_stop() &&  list_empty(&cwq->worklist)) schedule();－－－－－－－－－－－－－－（1） finish_wait(&cwq->more_work, &wait);try_to_freeze(); －－－－－－处理来自电源管理模块的冻结请求if (kthread_should_stop()) －－－－－处理停止该thread的请求 break;run_workqueue(cwq); －－－－－－依次处理work list上的各个work }return 0; 
}

（1）导致worker thread进入sleep状态有三个条件：

（a）电源管理模块没有请求冻结该worker thread。

（b）该thread没有被其他模块请求停掉。

（c）work list为空，也就是说没有work要处理

查看全文
如若内容造成侵权/违法违规/事实不符，请联系编程学习网邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！

3. IRQ number和中断描述符
1 前言 2 基本概念2.1 通用中断的代码处理示意图 2.2 中断的打开和关闭 2.3 IRQ number3 中断描述符数据结构3.1 底层irq chip相关的数据结构 3.2 irq chip数据结构 3.3 中断描述符4 初始化相关的中断描述符的接口4.1 静态定义的中断描述符初始化 4.2 使用Radix tree的中断描述…...
2024/4/24 9:46:51
5. 驱动申请中断API
1 前言 2 和中断相关的linux实时性分析以及中断线程化的背景介绍2.1 非抢占式linux内核的实时性 2.2 抢占式linux内核的实时性 2.3 进一步提高linux内核的实时性3 request_threaded_irq的接口规格3.1 输入参数描述 3.2 输出参数描述 3.3 Interrupt type flags4 request_threade…...
2024/4/24 9:46:50
9. tasklet[有完整中断(包括top和bottom half)调用示例]
1 前言 2 为什么需要tasklet？2.1 基本的思考 2.2 对linux中的bottom half机制的思考3 tasklet的基本原理3.1 如何抽象一个tasklet 3.2 系统如何管理tasklet？ 3.3 如何定义一个tasklet？ 3.4 如何调度一个tasklet 3.5 在什么时机会执行tasklet？1 前言对于中断处理而言，linu…...
2024/4/24 9:46:57
14. 中断唤醒系统流程
1 前言 2 中断唤醒流程2.1 enable_irq_wake 2.2 Suspend to RAM流程 2.3 resume流程 2.4 system core operations有什么用？ 2.5 gic interrupt controller中断执行流程 2.6 dpm_resume_noirq()1 前言曾几何时，不知道你是否想过外部中断是如何产生的呢？又是如何唤醒系统的呢…...
2024/4/29 10:33:29
HTTPS工作原理
当你打开浏览器，访问某个网站，如果网址旁有个小锁，代表访问的网址是安全的，反之不安全。当我们没有看到那个小锁的小图标的时候，需要提高警惕，不要随意输入个人重要的资料。所有的银行和支付相关的网站都是 100% 使用 HTTPS 的。为什么需要 HTTPS？我们为什么需要 HTTPS？…...
2024/4/24 9:46:47
开始好好学习开始写博客吧
总之开始试着写一下学习博客，希望能有所收获浑浑噩噩几年，感觉自己没学到什么东西，疫情期间在家学习实在是没有自觉。咬牙努力下，开始学着写一下博客，记录下接下来的变成学习生活。博客内容：平时作业学到的内容（当一个笔记本）、前端学习（目标）、课余感兴趣的知识记…...
2024/4/28 12:48:08
5月份Github上最热门的开源项目，已经新鲜出炉了！！
5月份GitHub上最热门的开源项目排行已经出炉啦，一起来看看上榜详情吧： 1，deno https://github.com/denoland/deno Star 61499 Deno 是 V8 上的安全 TypeScript 运行时。部分特性如下：支持 TypeScript 2.8 开箱即用，使用 V8 6.8.275.3 引擎无 package.json、npm，不追求兼…...
2024/5/2 16:05:51
Android Studio开发APP过程中发现的优质参考博客
作为一个应届毕业生，完成了两个APP的创作之后，现在开始管理收藏夹，所以将收藏夹的文章转移到此处。显然不是全部搜索的文章，在学习过程中你会搜索很多很多很多很多的文章，然后进行信息筛选和综合。这里只是冰山一角，还有一些确实很优秀但是内容比较精炼，被我吃透之后就…...
2024/4/16 9:47:16
Capsule Network Performance on Complex Data 翻译
1. 简介近年来，卷积神经网络（CNN）在深度学习领域中发挥了重要作用。事实证明，CNN的变体在跨不同领域的分类任务中非常成功。但是，CNN的主要缺点有两个：无法考虑要素之间的重要空间层次结构以及缺乏旋转不变性[1]。只要在测试数据中存在某个对象的某些关键特征，CNN便会将…...
2024/4/16 9:47:36
一文搞懂nmcli不能tab补全和全部使用方法
文章目录nmcli命令无法tab补全解决方案nmcli说明注意事项nmcli命令合集查看合集添加网络连接参数介绍合集添加单网卡实例修改网络连接单项参数介绍合集修改已经配置好的参数测试激活禁用删除等介绍合集总结测试实例添加单网卡实例nmcli做一个team双网卡绑定（链路聚合） nmcli…...
2024/4/16 9:48:13
由文章中英文字母出现频率分析破解密文
原题：使用频率分析法，尝试破译密文： WB WI KJB MK RMIT BMIQ BJ RASHMWK RMVP YJERYRKB MKD WBI IWOKWXWVMKVR MKDIJYR YNIB URYMWK NKRASHMWKRD BJ OWER M VJYSHRBR RASHMKMBWJK JKR CJNHD PMER BJ LR FNMHWXWRD MKD WKISWURD BJ INVP MK RABRKB BPMB PR VJNHD URMVP BP…...
2024/4/18 5:30:02
C++设计模式——单例模式(Singleton Pattern)
C++设计模式——单例模式(Singleton Pattern)微信公众号：幼儿园的学霸目录文章目录C++设计模式——单例模式(Singleton Pattern)目录定义代码示例懒汉模式线程/内存不安全方式智能指针+双检锁模式和智能指针+call_once模式局部静态变量模式饿汉模式总结参考资料定义单例模式…...
2024/4/15 6:03:04
Vue基础学习
到公司第一天，把快遗忘的vue再看一遍官网的文档。 Vue.js是什么？ Vue.js是一套用于构建用户界面的渐进式框架。声明式渲染下面展示一些内联代码片。 <div id="app"> {{mesage}} </div>var app = new Vue({el:#app,data:{message:Hello Vue!} })结果…...
2024/4/16 9:48:23
人人都是产品经理2.0-01章摘要总结
人人都是产品经理2.0-01章摘要总结1.1从一个小故事谈起（伪需求）1.2产品经理的前世今生1.3思维方式与性格特点1.3.1从学生到职场1.3.2从用户到产品经理1.3.3从现象到本质1.3.4还有什么性格特质是加分项1.4产品经理的日常1.5延伸阅读与练习 1.1从一个小故事谈起（伪需求）反映出…...
2024/4/19 8:56:40
实验三面向对象（上）
实验目的： 1．了解类的成员设计。 2．掌握类与对象的关系。 3. 掌握构造方法的重载及调用、掌握static关键字的、this关键字。 4.了解内部类的特点及使用。实验内容： 1.编写Java应用程序，定义时钟类Clock，包含3个int型成员变量hour，minute，second，分别表示时，分，秒，…...
2024/4/24 9:46:45
三、Linux进阶——Apache（web服务器部署）
1. Apache的作用在web被访问时通常使用http://方式 http:// 文本传输协议 http:// 超文本传输协议提供软件： Apache：目前主流 nginx：轻量级 stgw：腾讯 jfe：京东 Tengine：阿里巴巴 2. Apache的安装 dnf install httpd.x86_64 -y3. Apache的启用 1、启用Apache，并设定…...
2024/4/24 9:46:44
部署一套完整的Kubernetes高可用集群（上）
部署一套完整的Kubernetes高可用集群（上）原创阿良 DevOps技术栈今天目录[-]一、前置知识点1.1 生产环境可部署Kubernetes集群的两种方式目前生产部署Kubernetes集群主要有两种方式：kubeadmKubeadm是一个K8s部署工具，提供kubeadm init和kubeadm join，用于快速部署Kuberne…...
2024/4/24 9:46:44
redux4 - 处理有多个 reducer时如何合并，以及实现 combineReducers
参考源码redux仓库 redux原则之一就是单一性，即状态，仓库，reducer都是唯一的，但在组件式的技术开发中，为了好管理状态，通常一个组件，或嵌套组件对应一个 reducer，最后再合并成一个大的reducer代码太多，请参考演示代码代码演示两个组件的都有各自的组件状态，怎么进行…...
2024/4/24 9:46:42
【华为云技术分享】低代码开发平台发展趋势：低代码——炒作还是趋势？
在《人月神话》的开篇提到焦油坑，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。他们挣扎的越是猛烈，焦油纠缠的越紧，没有任何猛兽足够壮烈或具有足够的技巧，能够挣扎束缚，他们最后都沉到了坑底。大型软件系统开发…...
2024/4/24 9:46:41
UNSW 第五学期总结
我真是服了，老遇上百年未有之变局，先是建校以来第一次改成了三学期制，现在又遇上全球疫情。人生，刺激啊。这学期最大的问题就是，由于校内所有建筑尽数封闭，我完全找不到一个自习的地方，之前所总结的：千万不能在宿舍里学习，哦豁，其解决方案直接作废。现在只能在宿舍里…...
2024/4/24 9:46:40

10. workqueue的基本概念