vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

local/docs/ACPI-IMPROVEMENT-PLAN.md: remove references to deleted plans

Browse Source 
Per ground-truth: BOOT-PROCESS-ASSESSMENT.md, IOMMU-SPEC-REFERENCE.md, and LINUX-BORROWING-RUST-IMPLEMENTATION-PLAN.md are gone. Replaced with "(deleted)" markers. Lines 73-74 (duplicate BOOT-PROCESS-ASSESSMENT.md refs) collapsed to a single marker.
This commit is contained in:
vasilito
2026-07-13 19:41:55 +03:00
parent 67507071c0
commit 338892d3ec
1 changed files with 10 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
local/docs/ACPI-IMPROVEMENT-PLAN.md
+10 -14
View File
@@ -39,9 +39,9 @@ status claims, and backed by bounded runtime evidence.
## Purpose
This plan does **not** replace `local/docs/BOOT-PROCESS-ASSESSMENT.md` (historical boot record).
This plan does **not** replace the historical boot record.
- `local/docs/BOOT-PROCESS-ASSESSMENT.md` (historical boot record) remains the historical P0 bring-up ledger and implementation snapshot.
- The historical boot record remains the historical P0 bring-up ledger and implementation snapshot.
- This file is the forward plan for correctness hardening, ownership cleanup, consumer integration,
and validation closure.
@@ -70,12 +70,8 @@ kernel-ownership decisions are shared.
Read these alongside this plan:
- `local/docs/BOOT-PROCESS-ASSESSMENT.md` (historical boot record)
- `local/docs/BOOT-PROCESS-ASSESSMENT.md`
- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
- `local/docs/IOMMU-SPEC-REFERENCE.md`
- `local/docs/QUIRKS-SYSTEM.md`
- `local/docs/LINUX-BORROWING-RUST-IMPLEMENTATION-PLAN.md`
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
## Evidence Model
@@ -229,7 +225,7 @@ Without a contract, later hardening work turns into undocumented rewrites and do
### Primary files
- `local/docs/BOOT-PROCESS-ASSESSMENT.md` (historical boot record)
- the historical boot record
- this file
- `HARDWARE.md`
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
@@ -252,9 +248,9 @@ Without a contract, later hardening work turns into undocumented rewrites and do
| ID | Work slice | Concrete output | QA evidence |
|---|---|---|---|
| W0.1 | Vocabulary normalization | All ACPI-facing docs use the same status words for implemented / transitional / known gap | grep review across ACPI docs shows no conflicting support language |
| W0.2 | Ownership statement | One canonical statement for kernel / `acpid` / `iommu` / future DMAR ownership | `ACPI-IMPROVEMENT-PLAN.md`, `BOOT-PROCESS-ASSESSMENT.md`, and `IOMMU-SPEC-REFERENCE.md` agree |
| W0.2 | Ownership statement | One canonical statement for kernel / `acpid` / `iommu` / future DMAR ownership | `ACPI-IMPROVEMENT-PLAN.md` agrees |
| W0.3 | Eventing scope truthfulness | `kstop` and shutdown-only semantics become explicit everywhere they are summarized | `DBUS-INTEGRATION-PLAN.md`, `DESKTOP-STACK-CURRENT-STATUS.md`, and `AGENTS.md` stay aligned |
| W0.4 | Evidence-carrier cleanup | validation logs are treated as evidence carriers, not support-policy sources | `BOOT-PROCESS-ASSESSMENT.md` and `HARDWARE.md` no longer overclaim support |
| W0.4 | Evidence-carrier cleanup | validation logs are treated as evidence carriers, not support-policy sources | `HARDWARE.md` no longer overclaim support |
### Specific tasks
@@ -350,7 +346,7 @@ Remove catastrophic or silent failure behavior from boot-critical ACPI initializ
- boot-path evidence showing where AML bootstrap parameters come from or an explicit retained blocker stating that the producer remains unresolved,
- one bounded AMD hardware boot recheck,
- one bounded Intel hardware boot recheck,
- evidence captured in `local/docs/BOOT-PROCESS-ASSESSMENT.md`.
- evidence captured in the historical boot record.
### Exit criteria
@@ -577,7 +573,7 @@ Move from transitional ownership to a durable architecture that can survive long
|---|---|---|---|
| W5.1 | Kernel contract write-down | explicit minimal kernel ACPI contract in docs/comments | kernel/export surfaces match the written contract |
| W5.2 | DMAR carrier cleanup | orphaned `acpid` DMAR carrier is explicitly deferred unless a real Intel runtime owner is ready in the same implementation slice | no doc claims a hidden owner that code does not implement |
| W5.3 | IOMMU ownership alignment | IVRS/DMAR ownership text across `iommu` and ACPI docs becomes stable | `ACPI-IMPROVEMENT-PLAN.md`, `IOMMU-SPEC-REFERENCE.md`, and Linux-borrowing plan agree |
| W5.3 | IOMMU ownership alignment | IVRS/DMAR ownership text across `iommu` and ACPI docs becomes stable | `ACPI-IMPROVEMENT-PLAN.md` and Linux-borrowing plan agree |
| W5.4 | Regression containment | ownership cleanup does not break existing bring-up paths | before/after boot checks on AMD and Intel remain stable |
### Specific tasks
@@ -675,7 +671,7 @@ Turn the current ACPI stack from bring-up evidence into release-grade trust.
### Primary files
- `local/docs/BOOT-PROCESS-ASSESSMENT.md`
- the historical boot record
- `HARDWARE.md`
- this file
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
@@ -736,14 +732,14 @@ This plan should treat one successful run as **initial evidence**, not closure.
| ID | Work slice | Concrete output | QA evidence |
|---|---|---|---|
| W7.1 | Matrix carrier | one canonical bounded validation matrix exists | `BOOT-PROCESS-ASSESSMENT.md` holds named platform entries |
| W7.1 | Matrix carrier | one canonical bounded validation matrix exists | the historical boot record holds named platform entries |
| W7.2 | Positive proof set | QEMU + AMD + Intel + EC-backed paths each have bounded proof entries | repeated runs recorded with dates and configs |
| W7.3 | Negative-result discipline | unresolved AML/EC/platform failures stay visible | negative results persist in logs/docs instead of disappearing |
| W7.4 | Release-gate enforcement | stronger ACPI claims are tied to explicit gate passage | summary docs do not exceed the evidence in the matrix |
### Specific tasks
1. Publish the platform matrix in `local/docs/BOOT-PROCESS-ASSESSMENT.md`.
1. Publish the platform matrix in the historical boot record.
2. Record for each platform: firmware mode, key ACPI tables, APIC mode, shutdown / reboot, DMI / power exposure, AML / EC failures, and notable degraded behavior.
3. Preserve negative results such as unsupported AML opcodes or platform-specific regressions.
4. Require evidence before any stronger ACPI completeness claim is made.