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.
… depending on what you want to do.
Anything useful is still “unsafe.”
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.