Implement libstd for CloudABI. #47268
Conversation
|
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
EdSchouten
force-pushed
the
cloudabi-libstd
branch
2 times, most recently
from
8ffc7be to
72aaa08
Compare
kennytm
added
the
S-waiting-on-review
EdSchouten
force-pushed
the
cloudabi-libstd
branch
2 times, most recently
from
adf24d1 to
e7aa33c
Compare
sfackler
added
I-needs-decision
|
Thanks for the PR @EdSchouten! We discussed this PR at @rust-lang/libs triage today and we noted that one thing we'll probably want to do is keep the whole standard library compiling as-is on the cloudabi platform (e.g. continue to have Along those lines could this take a wasm-like approach which implements the entire |
These automatically generated Rust source files allow us to invoke
system calls within CloudABI processes. These will be used by libstd to
implement primitives for I/O, threading, etc.
These source files are normally part of the 'cloudabi' crate. In the
case of libstd, we'd better copy them into the source tree, as having
external dependencies in libstd is a bit messy. Original source files
can be found here:
https://github.com/NuxiNL/cloudabi/tree/master/rust
Though CloudABI is strongly inspired by POSIX, its absence of features that don't work well with capability-based sandboxing makes it different enough that adding bits to sys/unix will make things a mess. This change therefore adds CloudABI specific platform code under sys/cloudabi and borrows parts from sys/unix that can be used without changes. One of the goals of this implementation is to build as much as possible directly on top of CloudABI's system call layer, as opposed to using the C library. This is preferred, as the system call layer is supposed to be stable, whereas the C library ABI technically is not. An advantage of this approach is that it allows us to implement certain interfaces, such as mutexes and condition variables more optimally. They can be lighter than the ones provided by pthreads. This change disables some modules that cannot realistically be implemented right now. For example, libstd's pathname abstraction is not designed with POSIX *at() (e.g., openat()) in mind. The *at() functions are the only set of file system APIs available on CloudABI. There is no global file system namespace, nor a process working directory. Discussions on how to port these modules over are outside the scope of this change. Apart from this change, there are still some other minor fixups that need to be made to platform independent code to make things build. These will be sent out separately, so they can be reviewed more thoroughly.
As discussed in rust-lang#47268, libstd isn't ready to have certain functionality disabled yet. Follow wasm's approach of adding no-op modules for all of the features that we can't implement. I've placed all of those shims in a shims/ subdirectory, so we (the CloudABI folks) can experiment with removing them more easily. It also ensures that the code that does work doesn't get polluted with lots of useless boilerplate code.
There are some tests that need to be disabled on CloudABI specifically, due to the fact that the shims cannot be built in combination with unix::ext or windows::ext. Also improve the scoping of some imports to suppress compiler warnings.
Just like with wasm, we can't just import unix::ext and windows::ext. Our shims are not complete enough for that.
EdSchouten
force-pushed
the
cloudabi-libstd
branch
from
e7aa33c to
cc8565b
Compare
|
Hi Alex, Thanks to you and others for taking the time to discuss this! I have to say I only agree with this sentiment partially; I already had a set of patches that made a full I've just updated this pull request with three additional commits: one to put shims in place and two to make all of the tests/documentation build properly. Be sure to let me know what you think! Ed |
|
Hmmm... this is odd. Checks fail due to |
|
Looks like there may be a specific exception for these lines but the modification is triggering it again? |
|
(in that it should be fine to just tweak that exception logic) |
|
@bors: r+ |
|
📌 Commit 6a8d55a has been approved by |
alexcrichton
added
S-waiting-on-bors
|
Sorry if I'm being impatient, but is this pull request actually in bors's queue? I'm seeing most pull requests getting merged by bors within one day, whereas this one is taking almost three days. Just responding to this pull request to ensure it won't slip under the radar. There happened to be an outage on GitHub around the time this got approved. Maybe this interfered with it being queued? |
Implement libstd for CloudABI. Though CloudABI is strongly inspired by POSIX, its absence of features that don't work well with capability-based sandboxing makes it different enough that adding bits to `sys/unix` will make things a mess. This change therefore adds CloudABI specific platform code under `sys/cloudabi`. One of the goals of this implementation is to build as much as possible directly on top of CloudABI's system call layer, as opposed to using the C library. This is preferred, as the system call layer is supposed to be stable, whereas the C library ABI technically is not. An advantage of this approach is that it allows us to implement certain interfaces, such as mutexes and condition variables more optimally. They can be lighter than the ones provided by pthreads. This change disables some modules that cannot realistically be implemented right now. For example, libstd's pathname abstraction is not designed with POSIX `*at()` (e.g., `openat()`) in mind. The `*at()` functions are the only set of file system APIs available on CloudABI. There is no global file system namespace, nor a process working directory. Discussions on how to port these modules over are outside the scope of this change.
You can see the queue here - https://buildbot2.rust-lang.org/homu/queue/rust. |
|
Hey @petrochenkov. Thanks for the link. That's pretty useful! |
|
☀️ Test successful - status-appveyor, status-travis |
Though CloudABI is strongly inspired by POSIX, its absence of features that don't work well with capability-based sandboxing makes it different enough that adding bits to
sys/unixwill make things a mess. This change therefore adds CloudABI specific platform code undersys/cloudabi.One of the goals of this implementation is to build as much as possible directly on top of CloudABI's system call layer, as opposed to using the C library. This is preferred, as the system call layer is supposed to be stable, whereas the C library ABI technically is not. An advantage of this approach is that it allows us to implement certain interfaces, such as mutexes and condition variables more optimally. They can be lighter than the ones provided by pthreads.
This change disables some modules that cannot realistically be implemented right now. For example, libstd's pathname abstraction is not designed with POSIX
*at()(e.g.,openat()) in mind. The*at()functions are the only set of file system APIs available on CloudABI. There is no global file system namespace, nor a process working directory. Discussions on how to port these modules over are outside the scope of this change.