I don't know about Redox, but Phil's Rust OS (http://os.phil-opp.com/) seems to manage to minimize unsafe Rust and only use it to create some low level OS abstractions that can be safely used. It's pretty neat.
From the book[1]: A quick grep gives us some stats: The kernel has 16.52% unsafe code, a 50% improvement in the last three weeks. Userspace has roughly ~0.2%.
Some compelling projects (GPU) failed for lack of interest. The concepts behind those projects did not fail because most of the projects were isolated. The best time for open hardware is yet to come. Redox could accelerate that.
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.)
