操作系统架构:内核和标准库的互操作性

Question

我一如既往地感谢您在我的旅程中付出的时间和努力:)

因此，作为一个书呆子，我已经开始拉回操作系统如何工作的层次。我有一个问题是关于内核和标准库的，比如Linux的glibc，它充当函数包装器。

为什么操作系统需要一个用C编写的标准库？或者问另一种方式，你能用C之外的其他语言为Linux内核写一个标准库吗？

我假设STD库的语言可能依赖于为内核选择的语言。因此，在我们用C编写的Linux示例中，包装器STD库也需要是C。

我理解为什么内核通常需要STD库，所以这不是我在JIC中真正想要得到的，我并不清楚。

再次感谢！

Answer 1

让我们深入了解有关OS -用户空间通信的更多细节。你知道这是怎么回事吗？基本上，每个平台都使用自己的方法将所谓的syscall ->控制从用户空间转移到内核空间。例如x86使用int指令，x86-64使用syscall指令，arm使用swi等等。此外，每个平台都对如何在调用syscall指令之前建立参数和syscall号有自己的理解。让我们关注x86-64:例如，对于调用execve (syscall编号为0x3b)，这段代码就足够了。你可以试试。

section .text
    global _start
_start:                
    mov rax, 0x3b             
    mov rdi, cmd             
    mov rsi, 0
    mov rdx, 0
    syscall

section .data
    cmd: db '/bin/sh'
.end:

现在让我们来了解一下什么是execve libc函数。基本上，如果您深入研究libc代码，您将看到它是通向syscall函数的包装器(请参阅syscall.S以获取libc中的拱门)。这个syscall.S看起来与我们上面的示例非常相似：

    .text
ENTRY (syscall)
    movq %rdi, %rax     /* Syscall number -> rax.  */
    movq %rsi, %rdi     /* shift arg1 - arg5.  */
    movq %rdx, %rsi
    movq %rcx, %rdx
    movq %r8, %r10
    movq %r9, %r8
    movq 8(%rsp),%r9    /* arg6 is on the stack.  */
    syscall         /* Do the system call.  */

因此，基本上，正如user4098326和rcgldr所提到的- uspace和内核之间的互连是汇编代码，以及它上面的所有东西-只是包装器。因此，据我所知，所有这些包装器都可以用编写，而不仅仅是用C编写。

Answer 2

通用内核驱动程序通过文件操作来工作，如打开、关闭、读和写。

同样，内核也是完全用C编写的。

因此，由于这两个原因，我认为，我们不能用其他语言编写低级库调用。