我正在 linux 内核中编写客户端/服务器（是的。在内核内部。它的设计决定已经完成并最终确定。它不会改变）

服务器从原始套接字读取传入的数据包。这些数据包（原始套接字正在侦听）的传输协议是自定义的，类似于 UDP。简而言之，我不必监听传入的连接，然后派生一个线程来处理该连接。

我只需要处理该原始套接字上的任何 IP 数据报。我将继续在原始套接字上无限循环地读取数据包。在用户级等效程序中，我会创建一个单独的线程并继续侦听传入的数据包。

现在对于内核级服务器，我怀疑是否应该在单独的线程中运行它，因为：

1. 我认为 read() 是一个 I/O 操作。所以在 read() 的某个地方，内核必须调用 schedule() 函数来放弃对处理器的控制。因此，在原始套接字上调用 read() 后，当前内核活动上下文将被搁置（可能放入睡眠队列？），直到数据包可用。当数据包到达时，内核中断上下文将发出信号，表明在队列中休眠的读取上下文再次准备好运行。我在这里故意使用“上下文”而不是“线程”。因此我不应该需要一个单独的内核线程。

2. 另一方面，如果 read() 没有放弃控制，那么整个内核将被阻塞。

谁能提供有关如何设计服务器的提示？第 1 点提出的论点的谬误是什么？

我知道，如果 IP 有效负载 > MTU，那么路由器通常会将 IP 数据包分段。最后，使用 IP-ID、IP 分段偏移和分段标志字段在目的地组装所有分段的数据包。IP 有效负载的最大长度为 64K。因此，L4 移交 64K 的有效载荷非常合理。如果 L2 协议是以太网（通常是这种情况），那么 MTU 大约为 1600 字节。因此，IP 数据包将在源主机本身被分段。然而，快速搜索一下 Linux 中的 IP 实现告诉我，在最近的内核中，L4 协议是分段友好的，即它们试图通过移交大小接近 MTU 的缓冲区来为 IP 节省分段工作。

考虑到这两个事实，我想知道 IP 数据包在源主机本身被分段的频率。它有时/很少/从不发生吗？有谁知道linux内核中的碎片规则是否有例外（即是否存在L4协议对碎片不友好的情况）？这在其他常见的操作系统（如 Windows）中是如何处理的？一般来说，IP 数据包分段的频率如何？

对于某些结构，我可以选择使用分号或do关键字来分隔语句的结尾，如下until例所示。

但这是不可能的Kernel.loop。

有这样的原因吗？

我喜欢编程挑战，编写内核似乎是一个编程挑战。

不幸的是，内核特别难以测试，因为它们基本上是操作系统的核心，因此它们不能轻易地在操作系统之上运行。

但是，我知道可以模拟计算机硬件的称为虚拟机的应用程序。

使用虚拟机开发和测试内核（C+Assembly）的最简单/最好的方法是什么？

在尝试估计内核模块（通常是设备驱动程序）消耗的内存量时，我尝试使用size实用程序，它给出了 .ko（.bss、.data、.text 等）的静态内存区域的大小。所以我期望这些值的总和与插入模块后立即由lsmod命令给出的输出完全相等。

init() 函数中没有执行动态内存分配（kmalloc 或 vmalloc）以确保它不会导致差异。那么为什么会出现不匹配？

奇怪的是，大多数时候发现不匹配是固定的！！

命令输出如下所示

大小 chardev.ko

lsmod

我正在编写一个 Linux 内核模块，我想在同一部分中包含一些代码和相关数据。我用属性标签声明数据和函数，例如：

但是，当我这样做时，gcc 抱怨：

如果我没有用特定的部分名称声明函数，gcc 就可以了。但我希望函数和变量都在同一部分。

有没有办法用 gcc 做到这一点？我的 gcc 版本是gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2

我想使用 Visual C++ 为 x86 机器构建嵌入式内核。我有一些 C 和汇编代码文件要编译，我想以与 GRUB 等 Multiboot 引导加载程序兼容的方式将它们链接在一起。

我想知道 Windows XP 引导加载程序 ( ntldr) 是否真的使用了 Windows 内核 ( ntoskrnl.exe) 导入声明？

ntoskrnl.exe具有以下导入模块BOOTVID.dll：HAL.dll和KDCOM.dll. 所以这三个模块是最先被加载的。想象一下内核有另一个模块被声明为导入的。这会导致ntldr也加载它吗？还是ntldr只知道它应该加载这四个模块而没有办法改变它？

一些背景：

作为个人项目，我一直在用 C++ 开发内核。事情进展顺利，事实上我对内核领域的大部分可用 c++ 都有很好的支持（我已经实现了几乎整个 libc 和 libstdc++）。

RTTI 和异常支持是比较困难和特定于编译器的事情之一。现在我完全禁用异常，但 RTTI 是我想要的，因为类似的东西dynamic_cast可能非常有用。为了完成这项工作，我有一个 std::type_info 的基本实现，它与 g++ 的期望相匹配，然后我链接到 g++libsupc++.a和libgcc_eh.a. 这很好用。RTTI 像冠军一样工作！

问题：

我一直在玩弄一些优化选项，并希望有一天将 -mregparm 作为编译时选项。显然这是一个内核并且必须与汇编代码交互，有些函数在堆栈上没有参数时不能很好地发挥作用。为了解决这个问题，我使用以下宏：

再一次，这工作得很好。问题是当你做一个dynamic_cast. 编译发出对一些隐式定义的内部函数（在前面提到的支持库中定义）的调用，并且这样做尊重 -mregparm 标志。当然，由于我链接到系统的支持库，它们可能有也可能没有（在我的情况下它们没有）具有兼容的调用约定......导致漂亮的内核恐慌。由于这些函数是隐式的（我的任何文件中都没有原型）并且它们的名称很长，名称混乱，因此（几乎）不可能将我的 asmlinkage 属性添加到它们。

想到了 3 种可能的解决方案。

1. 忘记一起支持-mregparm。
2. 使用与内核相同的标志重新编译这 2 个支持库。这可能很烦人并且有点不切实际（我不知道它们是否可以与 gcc 构建完全隔离，并且工具链升级可能非常痛苦），但应该可以。
3. 以某种方式使编译器在调用特定 .a/.o 文件中的代码时忽略 -mregparm。

选项3可能吗？我的直觉是不，但我想我会问，因为这里有一些 g++ 大师:-)。

用于调度支持 10K 并发线程且 I/O 繁重但 CPU 使用率低的应用程序的最佳算法是什么？论文链接表示赞赏。