Aros/开发者/文档/资源/ACPI

第三，在 x86-64 上，我们已经拥有启动到空闲循环中的辅助内核。处理器由 kernel.resource 管理，并且它已经提供了有关其数量的信息。processor.resource 使用此信息并以抽象形式将其提供给用户软件。例如，如果您运行 ShowConfig，它将显示您有多少个 CPU。但是，只有引导 CPU 才会填写信息。目前无法在辅助内核上运行代码，这超出了任务范围。

不会发生的事情

1. 赏金规范指出 ACPITool 应该告诉谁使用这些信息。没有这样的机制，并且违反了 Amiga 系列操作系统概念，即注册谁使用了某个组件。任何人都可以 OpenResource("acpi.resource") 并使用它。

但是，我有一个使用 acpi.resource 的组件列表

kernel.resource 使用 APIC 数据来注册和运行 CPU。由 kernel.resource 注册。processor.resource 显示此信息。processor.resource 是抽象的，它不会报告 ID。在 AROS 中，使用其编号来标识 CPU 就足够了。0 是引导 CPU。kernel.resource 已经具有一个函数，用于提供其执行的 CPU 数量。
exec.library ShutdownA() 当前使用 acpi.resource 进行冷重启，现有功能足以满足此要求。它将很快重构，但想法会保持不变。
battclock.resource 使用 FADT 中的世纪寄存器编号。
vgah.hidd 将意识到 FADT 中的“无 VGA”标志。
pciusb.device 将通过 ACPI 检测 MacMini，并且在这台机器上将不需要“forceusbpower”参数。该列表可以扩展，我只是不知道哪些其他硬件容易受到电源错误的影响。
PS/2 驱动程序可以意识到“无 PS/2”标志...但是，我不想先深入现有的代码并重构它。但是，承诺在合理的时间内重构 PS/2 驱动程序。过去也考虑过以类似的方式进行操作，但由于它是一种“黑客”行为，并且不是访问这些内容的预期方式（这需要一个适当的 acpi aml 解析器），因此放弃了。关机需要 AML。重启不需要，复位寄存器定义是 FADT 的一部分。它只需要通过检索 acpi 表中公开的基本硬件设置和资源来设置 AROS，因为我们无法访问 DSDT 等提供的信息（因为缺少 AML 解析器）。

2. IRQ 路由。这本身就是一个相当复杂的任务。我将把 IRQ 配置留给其他任务。它可以是 ACPI 第二阶段或其他内容，例如“多处理支持”。基本的想法是实现 exec.library 的独立 MP 模拟，并能够在辅助内核上运行任务。这将不是一个 SMP，但它将是朝着这个目标迈出的第一步。它可以用于 CPU 密集型应用程序（例如视频播放器），方法是在可用内核上运行一些专用任务。因为 ACPI 资源应该使用从 ACPI 中获得的信息来设置系统，而不需要 AML。顺便说一下，这也应该包括配置 AROS 以使用通过 ACPI 表公开的 HPET。这意味着需要实现 HPET 支持。目前，timer.device 只能与传统计时器配合使用。

执行此操作将需要在处理器之间分配中断。我认为应该为此任务开发新的组件。kernel.resource 是一个微内核，它不应该变得臃肿，并且那里应该只保留最小的 MP 支持（识别、IPI，可能就是这些）。

3. 规范指出“信息应该以 Amiga 方式存储”。我认为在这个级别上没有必要这样做。没有必要将表转换为其他内容，因为表仍然存在，并且使用合适的内存很容易管理它们。在这些表之上引入额外的结构只会浪费 RAM，而不会带来任何新东西，例如 bootloader.resource，它目前已被 kernel.resource 的 KrnGetBootInfo() 取代（除了命令行解析）。我认为，提供一些抽象的 Amiga 风格信息是更高层组件的工作，这些组件在适当的地方提供此类信息。一个例子是 processor.resource，其数据不依赖于它从哪里获取。ACPI 就是 ACPI，它仅仅如此，它从设计上就是特定于体系结构的。但是，正如我所说，存在用于浏览表的 Amiga 风格 API。您可以通过 ID 查找所需的表，并且可以通过钩子枚举存储在数组中的数据。我还将添加一个用于枚举具有相同 ID 的多个表的函数（对于某些表，这是一个有效的用例），并添加带有选项的标签列表，例如“获取带有 OEM ID foo 的 DSTD”，这也将非常有用。

参考文献

SMP 系统中的 CPU 应该以某种方式注册，并且除引导 CPU 外，每个 CPU 都应该运行一个空闲线程。我认为停止 CPU 与运行空闲线程并不相同。引导 CPU 的 cpu_Dispatch() 中也有空闲循环。基本上是 while (no_task_to_run) halt;。这也停止了 CPU，只是处理了中断。

为什么使用两种方式来表示相同的信息？当前的 API 不方便吗？您可以在 kernel.resource 中检查当前的 MADT 使用情况。您不会自己遍历表，也不会自己遍历表中的数据结构。

那是 ioapic 的工作。除了设置 ioapic 以处理路由等之外，它几乎没有（如果有的话）理由被访问。但是，究竟如何处理中断？我认为默认情况下，它们会发送到所有 CPU。或者只发送到引导 CPU。顺便说一下，这现在是否相关，因为只有引导 CPU 实际上处理硬件？它们会被发送到所有 CPU。或者只发送到引导 CPU。默认情况下它们只发送到引导 AP，并且可以通过多种方式配置（包括发送到最不活跃的 AP - 我认为这是处理 IRQ 处理的最佳方式）。

禁用传统 PIC。
重新配置 PCI 设备以使用 APIC 中断。

资源必须自己解析所有信息，这将比以 AmigaOS 风格的方式公开信息更昂贵。它们不会解析所有表。它们会询问 acpi.resource：“给我这个表，并在其中找到这些结构”。您将获得您想要的确切内容，仅此而已。

然后定义空闲线程。一个在内核上空闲的任务 - 并让我们准确地了解内核空闲了多长时间，以衡量处理器负载等。

acpi.resource 使用 SetFunction() 安装 ShutdownA() 替换。目标是防止 exec.library 膨胀。因为我已经有了 EFI 版本的重启例程，所以现在我添加了 ACPI。

类似于 mpexec.library。它可以包含每个 CPU 的无传统版本的 SysBase。并在它们上运行任务调度程序。这的核心应该由当前的调度代码处理，方法是使用此任务的本地实例（每个 apic），而不是使用 execbase 版本。我曾在旧代码中通过 TLS 更改过调度程序以执行此操作，并且它似乎在引导处理器上运行良好 - 但我还没有开始在 AP 上启动调度程序，因为我不完全确定调度程序应该如何正确启动，并且怀疑它需要每个内核都拥有一个虚假的 vblank 中断来触发“引擎”。

我还为调度程序添加了上述更改以处理每个任务的时间使用情况统计（以及所有 apic 向量的中断处理程序，这些处理程序提供了一些关于 apic 角度的事件非常有趣的信息）。

IRQ 路由并不简单，但这并不是忽视它的理由/理由 - 赏金要求明确提到了这一点，因为 ACPI 资源应该使用来自 ACPI 的信息来设置系统，而无需 AML。关于 IRQ，我同意......所以，让我们定义需要做什么 1. 禁用传统 PIC。2. 重新配置 PCI 设备以使用 APIC 中断。这听起来很正确 - IRQ 处理代码需要使用 APIC 代码（我相信目前在内核资源中）而不是 PIC 代码（并且应该默认使用 PIC，除非找到其他选项），当 ACPI 资源确定我们有比 PIC 更好的选择时。如果找到 IOAPIC（通过必要的表格），那么我们需要配置它们来路由 IRQ 传输，这最好是传输到活动最少的核心 - 但这需要对大多数当前中断处理程序进行“修复”，以便它们在最少的情况下锁定对硬件资源的访问。

事实上，SysBase->IdleCount 和 SysBase->DispCount 现在正在工作，因此至少可以通过百分比来衡量使用情况。注意 DispCount 和 IdleCount 不足以计算 CPU 使用率。您需要测量 CPU 在空闲模式下花费的时间，并将其与总时间进行比较。有关更多详细信息，请查看 sam440/efika，它在特定时间点记录时间基计数器的值。是的，对于每个任务，它都会记录 CPU 在该任务上忙碌的时间。以同样的方式记录空闲时间。每秒它都会比较在空闲模式下花费的时间。

Therefore, CPU usage (in %) is defined as (idle_time * 100)

在经典 AmigaOS 上如何衡量使用情况？如果我要为经典版编写这样的实用程序，我会创建一个具有最低优先级的任务，并设置 tc_Switch 和 tc_Launch。我会测量 CPU 在其中花费的时间，并将其与系统时间进行比较。