问题标签 [osdev]

在初始化我的内核时，我有一些事情需要发生：1）需要启用分页，2）物理内存管理器需要从 grub 解析内存映射，3）各种启动代码需要访问需要的数据留在那里供以后使用（例如 GDT、IDT、内存管理结构）。

这些步骤之间的依赖关系让我发疯。对于高半部分，内核链接在其虚拟地址处，因此我提出的选项是 1）在程序集中启用分页，这将涉及跟踪所有多引导指针（在程序集中），因此它们仍然可以访问到物理内存管理器，然后将它们全部取消映射，2）将启动代码链接到其物理地址，然后进行一些指针操作以访问其物理地址处的内核结构，或者 3）不使用高半部分核心。

还涉及在编译时不知道物理内存量的情况下引导物理内存管理器。我很确定我必须在分配第一个结构时小心避免所有多重引导结构，或者先使用它们然后不要担心覆盖它们（尽管我仍然必须处理模块并且这种方法可能涉及在设置物理内存管理器时将多重引导表复制到我需要的已知位置）。

这些问题是我到目前为止避免使用更高半内核的原因。有没有人有一个很好的系统来解决这些依赖关系？也许这个 GDT 技巧的一些变化是在其链接/虚拟地址访问内核和在其物理地址访问多引导表，或者使用某种预定义的页表来避免上述问题，可能涉及 PSE？

我正在尝试根据此页面设置一个用于组装引导加载程序并编译和链接简单内核的工作环境：在此处输入链接描述

到目前为止一切顺利，但是我似乎无法解决此链接器错误：

ld 手册页在我看来太神秘了，并且没有对这个特定的错误消息给出任何答案。

（我使用的是 Windows 7 64 位）

一段时间以来，我一直对编写操作系统感兴趣。通过几个不同的站点，我遇到了一个有趣的概念（解释一下）：如果您开始使用#include 编写引导加载程序，那么您已经犯了一个致命的错误。

我已经阅读了 K&R，整本书在每节课中都包含了它。在学习 C 的过程中一直使用它，我不知道我学到了什么使用 stdio，什么没有。如果没有 stdio，你可以在 C 中做什么？

最近我拿起了我的一个旧项目并重新启动它，几乎从头开始。我已经病了一段时间，所以我有时间努力打击并实现大量功能。然而，我觉得实现一个好主意的一件事是模块加载。我想做模块的内核模式动态加载。

模块这个词有点模棱两可，正确的术语是加载库，例如内核模式驱动程序的 C 库的微型实现或IRQ 0和 1上的PIT和键盘等标准事物。我试图实现的方法有点自我维持；在我的内核将加载的模块方面，将在内核本身中使用以进入用户模式。

例如，我的内核使用了我自己实现的 C 库中的极少数函数。这些函数本身用于设置我的GDT、IDT、IRQ、ISR等。我想将这些函数抽象为内核可以加载和使用的库。这意味着内核本身将需要在第一阶段加载模块，然后再进行任何设置。

现在，我自己想到了几种方法来做到这一点，例如向这个库添加一个结构，其中包含一个函数指针表，这些函数指针分配了库本身中函数的地址。将库编译为aout-kludge文件，将库作为​​ void *加载到内核中（这没关系，因为我有一个工作分配器），然后计算出结构的偏移量，进入 void 指针那么多，并在内核中重新创建结构。这听起来好像行不通，因为需要分配函数指针表，这意味着库本身中需要有一个初始化函数。即使我知道地址，那怎么称呼？

我对如何实现这样的加载器一无所知，这是否值得？我想尽可能多地抽象，我的内核具有模块化设计。我也确实希望用这种方法加载驱动程序和其他东西，我只是不确定我将如何实现它。我已经尝试了各种方法，但都失败了。我应该怎么办？

对于 osx、gcc、现代 x86：

x86 分段硬件和分页硬件是如何使用的？

我正在尝试开发一个 C 函数来获取一些主板信息（名称、ID 等），但我找不到这些信息的存储位置。我查看了 CPUID，但在那里找不到与主板相关的任何信息（尽管有很多关于 CPU 的信息）。

有谁知道我从哪里可以得到这些信息？

非常感谢。

我正在编写一个在保护模式下运行的小型操作系统。我到了要加载自定义中断描述符表的地步，但我不知道从哪里开始。我已经阅读了 OS Dev wiki上的一些内容，但有一些问题需要回答。

在 OS Dev wiki 上，它说the first 32 (0-31) interrupts are reserved and used by the CPU, as exceptions, so don't use those for APIs or IRQs.问题是，如果我正在加载我的自定义中断表，我不需要为所有这些中断提供条目吗？

此外，wiki 声明 BIOS 将 IRQ0-7 映射到中断 8-15。如果是这种情况，IRQ中断不会与保留中断冲突吗？

有什么我没有得到的吗？中断 0-31 是在单独的表中还是什么？有人请指点我正确的方向并把事情弄清楚。

这参考了 InteI 的软件开发人员手册（订单号：325384-039US 2011 年 5 月），第 4.10.4.4 节“延迟无效”描述了 TLB 条目无效的潜在延迟，这可能在访问其分页结构条目的内存时导致不可预测的结果已经变了。

手册说……“在某些情况下，所需的失效可能会延迟。软件开发人员应该明白，在修改分页结构条目和执行第 4.10.4.2 节中推荐的失效指令之间，处理器可以使用转换基于分页结构条目的旧值或新值。以下项目描述了延迟失效的一些潜在后果： 如果修改分页结构条目以将 R/W 标志从 0 更改为 1，对由该条目控制其翻译的线性地址的写访问可能会也可能不会导致页面错误异常。 ”

让我们假设一个简单的情况，其中针对线性地址修改了页面结构条目（r/w 标志从 0 翻转到 1），然后立即调用相应的 TBL 无效指令。我的问题是——作为 TLB 延迟失效的结果，即使在调用 TLB 失效后，对相关线性地址的写访问也不会出错（页面错误）？

还是说“延迟失效”只能在页面结构发生变化的线性地址的“失效”指令没有发出时才会导致不可预知的结果？

我知道 Cosmos 和 SharpOS 已经制作了自己的编译器来从 C# 构建二进制代码，但是您可以使用 Microsoft 的 .NET AOT 来做同样的事情吗？将 C# 编译为 x86，即。我假设您必须省略 using 语句，就像操作系统开发中包含语句一样。任何反馈表示赞赏。谢谢

编辑：我想在内核开发中使用 C# 的主要原因是托管代码带来的内存管理，尤其是单个地址空间属性。是否有必要启动 JIT 编译器，然后编译 C#？还是那个时候环境仍然太残缺？感谢您的反馈

我正在开发一个小型操作系统，它将为每个进程使用单独的本地描述符表。我知道我需要使用该lldt指令从我的 GDT 加载 LDT 段。我的内核已经使用有效的 GDT 在保护模式下运行，但我无法弄清楚我的 LDT 的 GDT 条目应该是什么样子。我知道它的基地址应该指向我的LDT，但我不知道特权级别和其他属性应该是什么。这是代表我的 GDT 中的 LDT 条目的 NASM 代码：

如果您不熟悉 NASM 语法，则此表条目的基地址为 0x8000，限制为 511（总共 512 个字节，或 64 个条目）。我已经阅读了 i486 程序员参考手册中关于 GDT 和 LDT 的部分，但我无法完全理解我的 GDT 条目应该是什么样子。

无论如何，我像这样加载 LDT：

此代码导致处理器产生一般保护故障（我用中断处理它）。我想知道两件事：

1) 我是否在 GDT 中正确描述了我的 LDT？如果不是，需要改变什么？2)LLDT指令是否会因为我的 LDT 本身存在无效的选择器而失败？我阅读了 LLDT 指令规范，在我看来它甚至没有读取 LDT 的内存，但我只是想确保 LLDT 没有失败，因为我的 LDT 数据中有错字。