|
| 1 | +# Copilot Instructions for mctp-lib |
| 2 | + |
| 3 | +## Project Overview |
| 4 | + |
| 5 | +This is a **platform-agnostic MCTP (Management Component Transport Protocol) stack** implemented in Rust for the OpenPRoT project. The crate provides a bare-metal routing layer designed for embedded systems without std support. |
| 6 | + |
| 7 | + |
| 8 | +## Project State & Development Strategy |
| 9 | +**Current Status:** Early-stage project with minimal codebase (README + LICENSE only) |
| 10 | + |
| 11 | +When adding code, expect to create: |
| 12 | +- `Cargo.toml` with appropriate dependencies for embedded/no_std environments |
| 13 | +- `src/lib.rs` as the main library entry point |
| 14 | +- MCTP protocol implementation modules (packet parsing, routing, message handling) |
| 15 | +- Platform-specific transport bindings (I2C, PCIe, USB, etc.) |
| 16 | +- Error handling that works in both std and no_std environments |
| 17 | + |
| 18 | +## Architecture Principles |
| 19 | + |
| 20 | +### Protocol Implementation |
| 21 | +- **Standards Compliance**: Follow DMTF MCTP specifications precisely |
| 22 | +- **Transport Agnostic**: Core protocol separate from transport implementations |
| 23 | +- **Embedded-First**: Design for resource-constrained environments (no_std support) |
| 24 | +- **Security Focus**: Implement proper validation, bounds checking, and secure defaults |
| 25 | + |
| 26 | + |
| 27 | +## Development Guidelines |
| 28 | + |
| 29 | +### Rust-Specific Conventions |
| 30 | +- **Use `#![no_std]` by default** with optional std feature flag |
| 31 | + |
| 32 | +### Testing Strategy |
| 33 | +- **Unit tests** for packet parsing and protocol logic |
| 34 | +- **Integration tests** with mock transports |
| 35 | +- **Embedded testing** on actual hardware when available |
| 36 | + |
| 37 | +### Dependencies Management |
| 38 | +- **Minimal dependencies** - justify each addition |
| 39 | +- **Embedded-friendly crates only** (check no_std compatibility) |
| 40 | +- **Avoid async** unless specifically needed (prefer blocking APIs) |
| 41 | + |
| 42 | + |
| 43 | +Focus on creating clean, well-tested abstractions that can be easily integrated into larger firmware systems while maintaining security and reliability standards. |
| 44 | + |
| 45 | +## Pull Request Review Checklist |
| 46 | + |
| 47 | +- [ ] Code is completely panic-free (no unwrap/expect/panic/indexing) |
| 48 | +- [ ] All fallible operations return Result or Option |
| 49 | +- [ ] Integer operations use checked/saturating/wrapping methods where needed |
| 50 | +- [ ] Array/slice access uses get() or pattern matching, not direct indexing |
| 51 | +- [ ] Interior mutability uses try_borrow/try_borrow_mut, not borrow/borrow_mut |
| 52 | +- [ ] Interior mutability requires justification (RefCell/Cell can cause runtime panics) |
| 53 | +- [ ] Error cases are well documented and handled appropriately |
| 54 | +- [ ] Tests verify error handling paths, not just happy paths |
| 55 | +- [ ] No unsafe code added (crate enforces `#![deny(unsafe_code)]`) |
| 56 | + |
| 57 | +## Quick Reference: Forbidden Patterns |
| 58 | + |
| 59 | +| Forbidden Pattern | Required Alternative | |
| 60 | +|-------------------|----------------------| |
| 61 | +| `value.unwrap()` | `match value { Some(v) => v, None => return Err(...) }` | |
| 62 | +| `result.expect("msg")` | `match result { Ok(v) => v, Err(e) => return Err(e.into()) }` | |
| 63 | +| `collection[index]` | `collection.get(index).ok_or(Error::OutOfBounds)?` | |
| 64 | +| `a + b` (integers) | `a.checked_add(b).ok_or(Error::Overflow)?` | |
| 65 | +| `refcell.borrow()` | `refcell.try_borrow().map_err(\|_\| Error::BorrowConflict)?` | |
| 66 | +| `refcell.borrow_mut()` | `refcell.try_borrow_mut().map_err(\|_\| Error::BorrowConflict)?` | |
| 67 | + |
| 68 | +## File Organization |
| 69 | + |
| 70 | +- `src/lib.rs`: Single-file crate with Router implementation and tests |
| 71 | +- `Cargo.toml`: Minimal dependencies, Edition 2024 |
| 72 | +- No examples or additional modules currently |
| 73 | + |
| 74 | +When extending this crate, follow the existing patterns of const generic parameterization and handle-based resource management. |
0 commit comments