Rust is the future of systems programming, C is the new Assembly (Packt)

I would also love to help too

> 2. Many C language features have no corresponding Rust support. For example, it seems like impossible to construct a struct with bitfields.

That's one of the items on the FFI working group's list to work on.

These conclusions are generally met with a variation of the motte-and-bailey argument, i.e. that Rust has an "unsafe" mode where all the manageable evils of C are permitted, albeit with back-to-front declaration syntax, semantically significant scoping[-1], an unhelpful type system, and a single compiler whose intermediate language is only equivalent to C but which supports fewer hardware targets. The advocate will then ignore these concerns, describing an ideal where existing code is supplanted with an incompatible language for which there are fewer skilled programmers, no semantics formalized to a standards-language level and then immobilized in stone every dozen years or so, no independent implementation from even hardware vendors, no fifty-year history, and no nigh-universal acceptance outside its niche as Mozilla's in-house language for browser implementation.

So it's not unreasonable to put that line of argument to rest just on the back of Rust's immaturity as a language, regardless of its supposedly groundbreaking special features (which don't exist inside "unsafe" blocks), and the discussion moved forward perhaps to its conclusion.

Rust is a huge crock. The reasons why it looks good to some are that contemporary C++ is also a crock (e.g. for attempting parity with Rust); and because its advocacybots[0] soak up all the flak that its features and lack thereof should rather face. Oh, and also security[1], and indistinct references to studies supposedly proving how people[2] just aren't good enough to handle sharp-cornered objects. This is not substantially different from the 1996 Java deal[3], only now it's a good thing that there's not going to eventually be a sufficiently smart just-in-time compiler and prescient garbage collector.

>(...) having Redox's kernel and Linux linked together, providing a single kernel binary, and drivers for Redox co-exist in the same space, gradually supplanting Linux drivers.

This is known as driver or subsystem porting, and it's commonly discussed in terms of having the younger system built up without reimplementing "the boring parts". In the context of Rust this takes on a rather millennarian tone where, instead of an eventual Redox 6.0 having hardware support (filesystem, device mapper, network stack, etc.) parity with Linux 12.34, the latter would have been rewritten to exclude non-Rust languages. A cultural revolution, if you will; certainly a great leap forward. Ensuring that definitely all the bathwater is gone so it won't be proven innocent of causing all our problems.

[-1] beyond identifier shadowing, which has a dedicated warning setting encouraged by common best practice.
[0] it's interesting to compare recent Rust advocacy with some from 2017; the arguments are the same and the conversations never move forward, akin to the hog having successfully dragged the farmer into a bout of mud-wrestling and wound up happy whether he wins or loses.
[1] in the sense of a small category of pointer bugs which can certainly look complete to the amateur who's never seen other use cases, let alone put them to practice himself; but not (say) AB-BA races, dangling keys, context violations such as misordered locking, and so forth.
[2] cheapest possible subcontractors, who can't but whose bugs aren't immediately apparent.
[3] in particular, MMUs still don't exist, and knee-jerkably deadly hazards still lurk even in data the program has itself generated.

Those are challenges worth highlighting. They need not be showstoppers. The details matter and they'll have to be addressed individually. E.g.

> * Sticking points are the heavy use of intrusive data-structures alongside kernel APIs, e.g. `offsetof`. Providing safety around that means that you cannot use some of the APIs directly.

Rust can express some uses of intrusive data structures safely (e.g. https://docs.rs/intrusive-collections/0.8.1/intrusive_col...) so it comes down whether the implicit lifetime constraints in play in each situation are expressible.

> * Many APIs use raw pointers all over. How do you ensure safety around these APIs? For example, for VFS - do you do something similar to FUSE but *inside* the kernel for some subsystems?

Similar issue: raw pointers themselves aren't the issue --- they can be cast to references --- the question is, can you assign valid and useful Rust lifetimes to those references? And that depends on the invariants of the specific API. But the common idioms of C code (e.g., "pointer parameter guaranteed to be valid for the duration of the call") are easily translated into Rust.

> * Some of the kernel APIs make heavy use of the C preprocessor.

They'll have to be translated by hand into inline, possibly generic Rust code, or possibly into Rust macros.

> * In debugging, kernel backtraces would need to deal with backtraces inside the kernel code, alongside backtraces for the C code. I'm guessing that kernel developers would like to see demanded symbols in kernel oops reports.

Should be OK if the build-the-kernel-with-LLVM people are already getting those backtraces. Rust demangling has recently been standardized and there's a library to do it.

> * How would kernel Rust code unwind in panic situations? (I'm guessing `fn drop` calls would be skipped).

Unwinding out to the nearest C code is an option, but probably you just want panic to call BUG().

> * Problem domain is similar to loading Rust-based DSOs in userspace, for frameworks that are not originally written in Rust (think about a GIMP plugin, for instance). Perhaps we should tackle that problem first?

This is being done. E.g. Federico did librsvg, people are writing GStreamer plugins in Rust. https://github.com/sdroege/gst-plugin-rs

Why not (re-) try to do something like UDI (http://www.projectudi.org/) in Rust? I don't know much about driver development, but an abstract driver framework looks interesting: You write the framework (API) once, drivers once and two (or more) implementations (one for linux and one for Redox)... and can use the same driver on linux and Redox. Another pro: this would curcument the unstable linux driver API problem, con: overhead, a lot of work (more?).