这个问题是一个延伸为什么我们需要将缓冲区传递给系统调用才能返回信息？为什么系统调用不能在内部分配缓冲区？因为内存分配是将回调传递给系统调用的众多动机之一。
我想将分配回调传递给需要缓冲区的原始系统调用变体，因为原始系统调用可能知道在写入缓冲区之前要分配的缓冲区的大小。
许多文件系统 API（不仅是 posix/*nix，Windows/NT 也这样做）总是要求您传递 ax 字节路径缓冲区（x 可能是 256 或 1024 或 4096 或 MAX_PATH）。您仍然必须将 x 传递到函数中以指示缓冲区大小，如果函数需要的空间超过缓冲区允许的空间，则函数可能会失败。
是否存在系统调用无法调用用户空间函数的限制？是否可能，但很复杂，因为系统调用必须保留调用用户空间上下文和回调用户空间上下文？从线程切换的角度来看，所有系统调用都应该是原子性的，并且从系统调用中调用用户空间代码会破坏这种原子性吗？
答案1
系统调用运行内核代码。内核不信任用户模式代码，因此如果系统调用需要回调，它就无法在内核模式下执行该回调。它必须在用户模式下执行回调。
系统调用无法确定回调将执行什么操作。回调可能会进行自己的系统调用。例如，分配内存的回调可能需要调用系统调用，例如sbrk或mmap来为进程提供更多内存。因此，除了任何嵌套系统调用的执行上下文之外，内核还需要为待处理的系统调用维护一个额外的执行上下文。内核每个进程可以有多个执行上下文：这就是内核线程的用途。但现在这些上下文需要具有额外的结构，因为某些上下文嵌套在其他上下文中。
通过让系统调用将所有中间信息传递给进程可以避免这种额外的复杂性。让进程执行它想要的任何回调代码，然后在准备好时调用延续系统调用。这样，内核保持一个简单的执行模型（系统调用被调用，系统调用运行，系统调用返回），并且进程可以根据需要运行回调。
好了，你已经知道了：这就是现在的运作方式。进程可以进行系统调用来查询所需缓冲区的大小，然后进行另一个系统调用（可能是具有不同参数的相同系统调用号）来获取数据。
存在一个固有的困难，即在回调执行过程中数据可能会发生变化。系统调用不必是原子的，但它们必须在给定时刻呈现系统的一致视图。例如，进程可能尝试从文件读取数据，并且文件可能会在回调运行时增长。由于内核不能相信回调会在给定的时间内完成 - 或者实际上它会完成 - 内核无法在回调运行时阻止对文件的更新。因此，用户域代码在任何情况下都必须应对这个困难：当回调后代码运行时，所需的数据可能不再适合缓冲区。