Use relibc for "top half" libc support
sunfishcode opened this issue · 5 comments
relibc is a project to build a libc in Rust. Its "bottom half" is quite different from Mustang's bottom half, as Mustang's "bottom half" is organized around being a set of C-compatible wrappers around rustix/origin's safe-Rust-oriented APIs, while relibc's "bottom half" just translates directly from C-compatible APIs to system calls. It's a tradeoff; the two approaches each have their own advantages.
Mustang does not yet have much "top half" support, and this is an area that I myself am not expecting to focus on. If others are interested in working in this space, I'm open to discussing different options, but one option here would be to use relibc's top-half code, for things like vsnprintf, getpwuid, mktime, and many other things. Being part of the "top half", they should in theory be straightfoward to port to mustang's "bottom half".
I don't yet have a specific plan for how to organize the code for this, but if anyone's interested in working on this, please post about it here, and we can figure out an overall strategy.
I've been thinking about this for a while, and this effort seems like something I'd be really interested in. The way I see it, stuff like rustix and memchr and stuff build on top of core, and form a sort of librust almost, with much less surface area than libc, but probably most of the platform specific bits. Then c-scape could basically be in the same boat as std here, but implementing all the libc stuff.
Pinning down what goes where and what is important enough to promote to "librust" is going to be a pain. Bring in both sides libc-consumer and libc-provider seems like it'll help get the balance right though...
I do think we should prioritize ergonomic Rust APIs over ease of implementation for the top-half, at least to an extent.
Cool My experience in this space so far is that the criteria of "needed by Rust's std" and "needed by popular Rust crates" is a pretty good first approximation for what needs to be in this conceptual "librust". There are some tricky cases, like the getpwuid_r call in std;:env::home_dir, but most of the time, things seem to work out pretty well.
#125 is a PR which adds a new "top half" layer I'm tentatively calling "c-gull". It's separate from c-scape so that it can depend on std, while c-scape can focus on being no-std. I added several functions, including using the idea above to implement mktime with tz-rs, as well as printf, drand48, and getpwuid_r, and related functions, using crates and std features.
With c-gull, mustang has started to enter the top-half space, and in a way that fits the overall philosophy of using Rust-idiomatic libraries with libc compatibility as a separate layer. So looking forward, we may still consider using relibc for some things, but if we do, it'll be at the granularity of individual functions, rather than importing it as the whole top half. As such, we can close this issue, and consider relibc within the context of specific features.