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 在其中花費的時間，並將其與系統時間進行比較。