等待队列和工作队列，它们总是在一起吗？

Question

我一直在尝试更新关于在内核中睡觉的关于等待队列的理解。因此开始浏览bcmgenet.c的源代码(内核版本4.4)，它是负责驱动7xxx系列Broadcom SoC的驱动程序，用于他们的机顶盒解决方案。

作为探测回调的一部分，这个驱动程序初始化一个工作队列，它是驱动程序私有结构的一部分，并将自己添加到Q中，但我在任何地方都没有看到任何类型的阻塞。然后，它继续初始化一个工作队列，并在唤醒时调用一个函数。

现在进入驱动程序的ISR0，如果满足某些条件，则在其中包含一个显式调用调度程序作为ISR (bcmgenet_isr0)的一部分。现在AFAIK，这个调用被用来将工作推迟到以后，就像tasklet一样。

在此之后，我们检查一些MDIO状态标志，如果满足了这些条件，我们就会唤醒在流程上下文中被阻塞的进程。，但是进程到底在哪里被阻塞呢？

而且，大多数情况下，等待队列似乎与工作队列一起使用。是使用它们的典型方式吗？

Answer 1

作为探测回调的一部分，这个驱动程序初始化一个工作队列，它是驱动程序私有结构的一部分，并将自己添加到Q中，但我在任何地方都没有看到任何类型的阻塞。

我想你说的是等待队列头，而不是工作队列。我没有看到探针将自身添加到队列中的任何证据；它只是在初始化队列。

队列通过调用bcmgenet_mii_read()中的bcmgenet_mii_read()宏和bcmmii.c中的bcmgenet_mii_write()函数来使用。这些调用将被阻塞，直到它们等待的条件变为真，或者超时时间过去。它们被ISR0中断处理程序中的ISR0调用唤醒。

然后，它继续初始化一个工作队列，并在唤醒时调用一个函数。

它正在初始化工作项，而不是工作队列。由于将工作项添加到系统工作队列中，将从内核线程调用该函数。

现在进入驱动程序的ISR0，如果满足某些条件，则在其中显式调用调度程序作为ISR (bcmgenet_isr0)的一部分。现在AFAIK，这个调用被用来将工作推迟到以后，就像tasklet一样。

您指的是ISR0中断处理程序中的ISR0调用。这是将前面提到的工作项添加到系统工作队列中。它类似于tasklet，但是tasklet在软in上下文中运行，而工作项在进程上下文中运行。

在此之后，我们检查一些MDIO状态标志，如果满足了这些条件，我们就会唤醒在流程上下文中被阻塞的进程。但是，这个过程到底在哪里被阻止呢？

如上所述，进程在bcmgenet_mii_read()和bcmgenet_mii_write()函数中被阻塞，尽管它们使用超时来避免长时间的阻塞。(这种超时对于那些不支持与MDIO相关的中断的GENET版本尤为重要！)

而且，大多数情况下，等待队列似乎与工作队列一起使用。这是典型的使用方法吗？

不是特别的。这个特定的驱动程序同时使用等待队列和工作项，但我不认为它们是“结合使用”的，因为它们用于处理不同的中断条件。