[PROJECT 3 PR 2] feat: implement Hardware Discovery Service for cross-platform orchest…

[mandeepsingh2007]

📋 Summary

Implement a Hardware Discovery Service within mofa-foundation that dynamically detects the host machine's OS, CPU architecture, and basic GPU availability. This is a prerequisite for the multi-backend dispatch logic in the General Model Orchestrator (e.g., routing to MLX on Mac or Candle on Windows).

🔗 Related Issues

#221

---

🧠 Context

As part of the GSoC 2026 General Model Orchestrator project, the orchestrator needs to know what hardware it's running on before it can route inference to the correct backend. This PR adds a lightweight, zero-external-dependency hardware detection module that identifies the OS, CPU family (including Apple Silicon distinction), and provides basic GPU availability stubs.

---

🛠️ Changes

• Added crates/mofa-foundation/src/hardware.rs with HardwareCapability struct, OsClassification and CpuFamily enums, and detect_hardware() function.
• Exported the new hardware module in crates/mofa-foundation/src/lib.rs.
• Added unit test test_detect_hardware() to validate the detection logic.

---

🧪 How you Tested

1. cargo build --workspace — builds successfully with zero new warnings.
2. cargo test -p mofa-foundation hardware — hardware test passes.
3. cargo clippy — no warnings from changed files (only pre-existing warning in mofa-plugins).

---

📸 Screenshots / Logs (if applicable)

---

⚠️ Breaking Changes

• No breaking changes

---

🧹 Checklist

Code Quality

• Code follows Rust idioms and project conventions
• cargo fmt run
• cargo clippy passes without warnings

Testing

• Tests added/updated
• cargo test passes locally without any error

Documentation

• Public APIs documented
• README / docs updated (if needed)

PR Hygiene

• PR is small and focused (one logical change)
• Branch is up to date with main
• No unrelated commits
• Commit messages explain why, not only what

---

🚀 Deployment Notes (if applicable)

None — no migrations, config changes, or env vars required.

---

🧩 Additional Notes for Reviewers

• GPU detection is intentionally a basic stub (checks for nvidia-smi on Windows/Linux, assumes Metal on Apple Silicon macOS). This will be expanded in a future issue.
• No external dependencies were added; the module uses only std::env::consts and std::process::Command.

[BH3GEI]

Hey, thanks for the PR. Before we merge this, a couple things worth addressing — the GPU detection on macOS currently only returns true for Apple Silicon, but Intel Macs support Metal too, so that logic is off. Similarly the nvidia-smi check on Linux/Windows is pretty rough since it misses AMD/ROCm and Intel GPUs entirely, and .is_ok() only tells you the binary exists, not that a GPU is actually usable. Also right now nothing in the codebase actually calls this module, so it would land as dead code in mofa-foundation.

What's your plan for the next steps here? Curious how you're thinking about wiring this into the actual orchestrator.

[mandeepsingh2007]

@BH3GEI thanks for the detailed review you've raised valid points here's how I plan to address them:

1. GPU Detection Improvements:

• macOS: I'll update the logic to return gpu_available = true for all macOS systems (since Metal is supported on both Apple Silicon and Intel Macs with macOS 10.14+), not just Apple Silicon.
• Linux/Windows: I'll expand beyond just nvidia-smi to also check for AMD GPUs (via rocm-smi) and Intel GPUs (via sycl-ls or checking for integrated graphics). I'll also validate that the GPU is actually usable rather than just checking binary existence — e.g., parsing nvidia-smi output for device status.

2. Wiring into the Orchestrator:
My next steps are:

• Define an InferenceBackend trait (pluggable backend abstraction as outlined in the project spec).
• Have the ModelOrchestrator (from PR [PROJECT 3 PR 1] feat: add ModelOrchestrator trait #166) consume HardwareCapability from this module to make routing decisions — e.g., selecting the MLX backend on Apple Silicon vs. Candle on Windows/CUDA.
• This will ensure the hardware module is actively used and not dead code.

3. Roadmap (next PRs):

• PR 3: InferenceBackend trait definition
• PR 4: ModelPool for concurrent model instance management
• PR 5: Wire hardware detection → orchestrator → backend selection

happy to discuss the design further before I start implementing

[BH3GEI]

Sounds good. Go ahead and fix the GPU detection issues first, then we can move forward from there.

[BH3GEI]

Thanks for the quick fix, looks good now. Merging.