So you take care with the bits that have to deal with C, just like you have to with C code itself, and then all the rest of your code is still safe by default. Still a net improvement, yes?
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.
So you take care with the bits that have to deal with C, just like you have to with C code itself, and then all the rest of your code is still safe by default. Still a net improvement, yes?
Yes, then they shouldn’t say it is “safe” because it isn’t. They should say “more safe”, or be more specific.
In a driver what else is there? Either you deal with c or hardware.
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.