Not sure if this is the right place to discuss this, but I’ve been messing around with a kernel in Rust for a while now, and would like to start experimenting with trying to get a Rust program running in userspace. So far, I’ve added a new target to
rustc and done a little work (such as some stuff in
liballoc_system and whatnot - I don’t think this’ll ever get upstreamed but I can always hope ).
However, I don’t really want to end up with a
libc implementation in my userspace. I’ve begun porting
libstd, and noticed that a lot of stuff just calls the equivalent function in
libc. While I’m more than willing to reimplement these functions in
libstd directly in Rust, I’m now a little worried about how difficult porting crates that directly depend on
libc will be - would it be better to just bite the bullet and maintain a fork of something like
relibc. Am I asking for trouble in trying to avoid
libc, or is there any interest in avoiding it on platforms where it isn’t needed?
It’s definitely possible to implement
libc. I’m currently running such a setup in production. As you correctly point out, though, crates might depend directly on
libc. That’s probably the case because
std doesn’t directly expose the needed functionality. This means you’ll need to maintain a fork of those crates implementing the functionality another way, or just removing the affected functionality all together. You might have to maintain those forks too, since not all upstream crates are amenable to upstreaming such changes (see e.g. rand, chrono, yasna).
Other types of crates might depend on C libraries that themselves depend on
libc. My strategy there so far has been to
- Copy parts of musl C for things that are just pure computation (
- Comprehensively edit the C source to modify/remove I/O related stuff to better work with Rust primitives (
- Implement some functions directly in Rust as
#[no_mangle] extern "C" fns (
This is also a lot of work.
The portability working group exists to come up with a better answer to the type of questions you raise. I just added an issue specific to libc. You might want to check out the website or join us on IRC:
IRC: #rust-portability on irc.mozilla.org
Hmm, interesting that some crate maintainers seem so against this sort of stuff, although I guess it’s on the more esoteric side of Rust. However, it’s good to see other people interested in this, and I’d love to get involved in the WG!
So all in all it seems a little touch and go how far I’ll get (although looks like that could improve in the future), but I’ll see how far I can get with
std and take it from there
Thanks for the reply, definitely interesting to see other people’s thoughts on this!
I do understand the maintainers's perspective: say 100 platforms get added this way, is it on them to support them all? I suppose part of the portability WG's mission is to reduce the burden on crate maintainers.