chore(scheduler-sim-diagnostics): mark container-only task groups complete
Tasks 2 and 3 are container-only major headers (per tasks-generation.md's hierarchy rule); all their executable sub-tasks (2.1-2.3, 3.1-3.2) are already complete. Bookkeeping only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
This commit is contained in:
parent
57b93f2942
commit
77924f787e
1 changed files with 2 additions and 2 deletions
|
|
@ -8,7 +8,7 @@
|
|||
- _Requirements: 1.1, 1.2, 1.4, 2.1, 3.1_
|
||||
- _Boundary: Limit Plugin Accessor_
|
||||
|
||||
- [ ] 2. Core: Limit lookup and configured-setting display
|
||||
- [x] 2. Core: Limit lookup and configured-setting display
|
||||
- [x] 2.1 Implement name/all resolution with correct absence messaging
|
||||
- New white-box test file `test_repl_limit_table.c` created (sibling of `test_repl_resource_table.c`, own `#include` set covering `plugins/limit.c` and `resource.c` for real — not stubbed — per `design.md`'s build-wiring risk note citing bug-1762's precedent)
|
||||
- `repl_info_limit(sim, arg)`: `arg == "all"` iterates `limit_get_configured_limits()`; `NULL`/empty prints "no limits configured" (Requirement 1.7); `arg != "all"` does a `key_find()` by name (not a scan) on the same handle, printing "no such limit '<name>'" (Requirement 1.3) for a `NULL` handle or a miss — a `NULL` handle on this path is never treated as "no limits configured," matching that message's own `all`-only scoping
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
- Observable: two REPL fixtures — one percent-based limit on a per-host resource without explicit per-host scoping (note appears), one absolute-value or explicitly-global-scoped limit (note does not appear)
|
||||
- _Requirements: 1.6_
|
||||
|
||||
- [ ] 3. Core: Live accounted-usage display
|
||||
- [x] 3. Core: Live accounted-usage display
|
||||
- [x] 3.1 Display usage for cluster-wide (non-host-scoped) limit instances
|
||||
- Iterate `limit_get_usage_instances()`, filter by `vres->limit == matched_limit`; for a GLOBAL/SHARED `vres`, read capacity from `core.sharedInst[idx]` and accounted usage from `core.sharedInUse[idx]`
|
||||
- Existence-of-instance and zero-usage are distinct: zero matching `xce_vres_t` (no capacity entry at all) prints "no active usage instance yet" (Requirement 2.2); a matched `xce_vres_t` whose `sharedInUse[idx]` is `NULL`/absent instead displays a genuine `accounted=0` (it has been evaluated and has a real capacity, just nothing charged against it yet) — existence is gated on the capacity read, never on the in-use read
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue