Commit bddcd0dc authored by Jeremy Soller's avatar Jeremy Soller

Merge branch 'master' into 'master'

RSoC: Final blog post

See merge request !202
parents f27881aa 94600a7e
Pipeline #994 passed with stage
in 28 seconds
title = "RSoC: Relibc - Wrap up"
author = "jD91mZM2"
date = "2018-08-11T07:35:26+02:00"
# \o
Well, it is nearing my RSoC project end date! Time for me to pack up and never
ever contribute to Redox ever again... Just kidding. This isn't goodbye, you
can't get rid of me that easily I'm afraid. I'll definitely want to contribute
more, can't however say with certainty how much time I'll get, for school is
approaching, quickly :(
Most importantly I'll want to continue rebasing mio and tokio and therefor
breaking the redox build process with missing git references in the Cargo.lock,
until [they are upstreamed](, and
after that I might still need to maintain it because of the policy for adding
new platforms. I am a little sad that it's taking so long to get things merged,
but it *is* a big change and stuff has to be considered.
## Actual relibc news
Continuing off from last time, we have a few goals completed:
- gcc_complete now compiles without any `unimplemented!()`s. We still have
some unimplemented functions due to missing system calls, but these are now
acknowledged by printing them out to stderr instead of panicking.
Everything is implemented on linux.
- redox itself also compiles without any `unimplemented!()`s
- openssl compiles with [sajattack's WIP
changes. Have yet to test runtime, but I expect a lot of things will
ultimately fail.
- dash and bash both compile and work! This is a pretty exciting goal because
that means we are actually testing programs that people use in practice.
Compiling bash requires some changes to the autotools configs, which for
some reason doesn't detect that we have all the features. See [this cookbook
- ffmpeg compiles and works! This is not too surprising considering it
shouldn't be too platform-specific, but it's always a good test! Didn't have
png support initially, but I'm not sure it did that on newlib either. [It
does now!](
## Epilogue
I'll need to come back and fix openssl after the project is over, but I'm happy
that we got so many things compiling! It shows that relibc isn't as far off of a
reality than I thought. Before I began this project I honestly didn't think it'd
take off anywhere, and definitely not compile redox. But now it does compile
redox and even bash inside it!
I'm a little annoyed by relibc' use of cbindgen, even though it's nice having
the headers be automatically generated, it's a little backwards since we should
write functions that adapt to them, not the other way around. It also forces us
to make one sub-crate per header, which leads to a lot of noise, and even worse,
causes a large pile of issues with recursive dependencies that are worked around
by linking in an old C fashion.
More-over, it's not clear what relibc's safety story is. Some relibc functions
are implemented safely. Some use safe Rust things, like slices, but in an unsafe
way. Some just use unsafe things like raw pointers directly. I lean towards the
latter when writing personally, because it is faster to be unsafe and don't look
up the length first. But I'd very much like to see one day where the only
unsafety in relibc is wrappers around inner, safe, functions. This unfortunately
doesn't make a lot of sense for platform-specific functions because Linux does
require pointers and stuff, so having a safety wrapper is just redundant. It
also requires us to restructure it a lot if we want to keep things clean.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment