rust "unsafe" is not about proprietariness of the hardware. It's about doing lower level operations that, in order to express, the rust compiler's safety logic must be disabled.
The point I'm trying to make is that open hardware could also be programmed in Rust, reducing the number of "unsafe" blocks in user applications. Software for proprietary hardware is usually written in unsafe C/C++.
I think what you're trying to say is that architecture-specific code will be isolated in unsafe blocks. That's not necessarily true, as a lot of safe code can definitely benefit from knowledge of the underlying metal. I'm thinking of scheduling in particular.
"unsafe" is a superset of "safe" Rust. There are exactly 3 things you can do in unsafe code that you can't do in safe code: access/modify a global mutable variable, dereference a raw pointer and call other unsafe functions. That's it.
No inline assembly? No ability to manipulate the bits of a pointer for stuff like alignment in a memory manager?
This is truly awful. It means you need to carry around a C compiler for the low-level parts. You could also use assembly, but then you're forced to write whole functions in assembly.
There is something else missing AFAIK. It's not quite as critical, but it sure helps: bitfields
This was done rather badly in C, reducing portability by not letting the programmer fully specify the layout. Normally we mostly ignore portability; for x86 gcc and Visual Studio are compatible.
Imagine writing an x86 emulator which might run on hardware of either endianness. In theory, bitfields are perfect for implementing the GDT, LDT, and IDT. Bitfields are also great for pulling fields out of opcodes. Unfortunately, bitfield layout in C is undefined. The same trouble hits when parsing a file, for example a flash animation file.
One should be able to specify spans of bytes with chosen endianness and bit order, then subdivide each span into fields. Normally each bit should belong to exactly one field, with an error if violated, but it should be possible to define overlapping fields if the programmer insists. Fields should then be able to be joined into larger fields, even if they come from different byte spans. This allows handling split fields such as the x86 descriptor's base and limit or the PowerPC opcode SPR encoding.
Lack of bitfield support and lack of a "restrict" keyword are probably the two biggest things holding me back from rust now.
Rust automatically adds the appropriate 'restrict' annotations to `&mut T` pointers, or well, does generally, but I think an LLVM bug made us take it off temporarily. Point is, this isn't something that you annotate in Rust like you do in C, you use the type system and the compiler handles it where appropriate. (It's more than just &mut T, like, UnsafeCell will also cause the annotation to _not_ happen, for example.)
