In a driver, there’s a lot more than just C and hardware interaction. You also have to deal with:
Concurrency and Synchronization – Managing locks, spinlocks, atomic operations, and ensuring safe access to shared resources.
Memory Management – Allocating kernel memory safely, handling DMA buffers, and avoiding memory leaks or invalid accesses.
Interrupt Handling – Dealing with IRQs, deferring work using tasklets, workqueues, or bottom halves.
State Management – Handling suspend, resume, and power states efficiently.
Error Handling and Recovery – Ensuring robustness in the presence of hardware failures or unexpected states.
Device Trees and ACPI – Parsing platform configuration data.
Firmware Communication – Loading and interfacing with device firmware blobs.
Kernel APIs and Subsystems – Interacting with networking, block devices, input devices, and other kernel frameworks.
Performance Optimizations – Managing cache coherency, NUMA awareness, and latency-sensitive operations.
Security Considerations – Preventing privilege escalation, ensuring safe user-space interaction, and sandboxing where applicable.
Yes, interfacing with hardware often requires unsafe Rust or C, but a lot of driver logic isn’t directly interacting with raw hardware registers. Rust can help improve safety in many of these areas by reducing common C pitfalls like use-after-free, null dereferences, and buffer overflows.
I wanted to reply that snapraid or the equivalent will lead to less wear and tear, and provide reasonable redundancy that you can trigger as needed. It’s also a lower electricity bill and allows mismatched drive sizes.
It’s also arguably easier to recover data on failures.
Can’t help with the drive costs unfortunately.