about summary refs log tree commit diff
path: root/src/libstd/os
AgeCommit message (Collapse)AuthorLines
2019-04-22Remove double trailing newlinesvarkor-9/+0
2019-03-29Add a new wasm32-unknown-wasi targetAlex Crichton-0/+7
This commit adds a new wasm32-based target distributed through rustup, supported in the standard library, and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem, networking, threads, etc. Instead it only provides the most basic of integration with the wasi syscalls, enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit, abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target, but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime], but more will surely emerge! In terms of future development of libstd, I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls, but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear, therefore, how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit, but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust, and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library, there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot, for example, provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management, process exit, and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way, if Rust and C are linked into the same WebAssembly binary they should work together, but that requires that the same C standard library is used. We also, however, want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind, there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go, a fully workable wasi binary pops out. This is incompatible with linking in C code, however, which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code, the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag, but the idea is that you're no longer using the provided static C runtime, but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols, but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:
2019-03-05SGX target: Expose thread id function in os moduleJethro Beekman-0/+5
2019-02-28libstd => 2018Taiki Endo-119/+93
2019-02-06Rollup merge of #58182 - jethrogb:jb/sgx-bytebuffer-len-0, r=joshtriplettkennytm-1/+1
SGX target: handle empty user buffers correctly Also, expose correct items in `os::fortanix_sgx::usercalls::alloc` * [read_alloc documentation](https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#method.read_alloc) * [Clarified ByteBuffer documentation](https://github.com/fortanix/rust-sgx/pull/94/files#diff-ca843ad9e25cacd63a80579c0f7efa56) r? @joshtriplett
2019-02-05Expose correct items in `os::fortanix_sgx::usercalls::alloc`Jethro Beekman-1/+1
2019-02-01Fix `std::os::fortanix_sgx::usercalls::raw::UsercallNrs`Jethro Beekman-16/+1
Fixes https://github.com/fortanix/rust-sgx/issues/88
2019-01-23Add os::fortanix_sgx::ffi moduleJethro Beekman-1/+1
2018-12-27Auto merge of #57119 - jethrogb:jb/sgx-os-mod2, r=joshtriplettbors-0/+2
Add `io` and `arch` modules to `std::os::fortanix_sgx` This PR adds two more (unstable) modules to `std::os::fortanix_sgx` for the `x86_64-fortanix-unknown-sgx` target. ### io `io` allows conversion between raw file descriptors and Rust types, similar to `std::os::unix::io`. ### arch `arch` exposes the `ENCLU[EREPORT]` and `ENCLU[EGETKEY]` instructions. The current functions are very likely not going to be the final form of these functions (see also https://github.com/fortanix/rust-sgx/issues/15), but this should be sufficient to enable experimentation in libraries. I tried using the actual types (from the [`sgx-isa` crate](https://crates.io/crates/sgx-isa)) instead of byte arrays, but that would make `std` dependent on the `bitflags` crate which I didn't want to do at this time.
2018-12-25Remove licensesMark Rousskov-450/+0
2018-12-25Add `io` and `arch` modules to `std::os::fortanix_sgx`Jethro Beekman-0/+2
2018-12-20Add `std::os::fortanix_sgx` moduleJethro Beekman-0/+68
2018-12-19Show platform-specific modules in `std::os` when building those platformsJethro Beekman-17/+16
2018-12-09Add FreeBSD unsigned char platforms to std::os::rawmyfreeweb-0/+8
Reference: https://www.freebsd.org/cgi/man.cgi?query=arch&apropos=0&sektion=7
2018-11-22Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearerariasuni-6/+12
2018-09-14Move std::os::raw::c_void into libcore and re-export in libstdIsaac Woods-35/+2
2018-09-01Rollup merge of #53076 - QuietMisdreavus:cfg-rustdoc, r=GuillaumeGomezkennytm-1/+1
set cfg(rustdoc) when rustdoc is running on a crate When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation. This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs. To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
2018-08-31use cfg(rustdoc) instead of cfg(dox) in std and friendsQuietMisdreavus-1/+1
2018-08-29Replace usages of 'bad_style' with 'nonstandard_style'.Corey Farwell-1/+1
`bad_style` is being deprecated in favor of `nonstandard_style`: - https://github.com/rust-lang/rust/issues/41646
2018-08-07Add aarch64-unknown-netbsd targetJonathan A. Kollasch-2/+4
2018-08-06NetBSD: fix signedess of charJonathan A. Kollasch-0/+4
2018-07-30Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and ↵Colin Finck-0/+433
port libstd to it. As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic) and makes use of existing Unix-specific code wherever possible. It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform under development). Together with the patches to "liblibc" and "llvm", this enables HermitCore applications to be written in Rust.
2018-04-14Add doc links to `std::os` extension traitsDylan MacKenzie-13/+39
Add documentation links to the original type for various OS-specific extension traits and normalize the language for introducing such traits. Also, remove some outdated comments around the extension trait definitions.
2018-03-28Remove hidden `foo` functions from doc examples; use `Termination` trait.Corey Farwell-119/+119
Fixes https://github.com/rust-lang/rust/issues/49233.
2018-02-06fix docs linkQuietMisdreavus-1/+1
2018-01-29Reworded to avoid fuzziness, mention ! in c_void docs.Clar Charr-13/+23
2018-01-29Revisions suggested in commentsClar Charr-6/+4
2018-01-29Document std::os::raw.Clar Charr-5/+115
2017-12-17add aarch64-unknown-openbsd supportSébastien Marie-0/+2
- make liblibc to point to libc with aarch64-unknown-openbsd - make c_char (in std::os::raw) to point to right value
2017-11-25rustbuild: Enable WebAssembly backend by defaultAlex Crichton-30/+48
This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!
2017-10-24Fix doc build on other architectures than linuxGuillaume Gomez-17/+17
2017-10-19Add missing code examplesGuillaume Gomez-1/+241
2017-10-05Remove nacl from libstdest31-201/+0
2017-09-08Add modifications needed for L4re in libstdTobias Schaffner-1/+1
This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220a84e40b65e45308cc0f3bbea4466d3acf In many aspects implementations for linux also apply for the L4Re microkernel. Two uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
2017-09-08Match c_char definitions and enable signal reset for L4ReSebastian Humenda-0/+2
* Match definition of c_char in os/raw.rs with the libc definition Due to historic reasons, os/raw.rs redefines types for c_char from libc, but these didn't match. Now they do :). * Enable signal reset on exec for L4Re L4Re has full signal emulation and hence it needs to reset the signal set of the child with sigemptyset. However, gid and uid should *not* be set.
2017-08-28Update the libc submoduleAlex Crichton-4/+2
Brings in a few fixes for wasm/asmjs
2017-08-10Exposed all platform-specific documentation.kennytm-16/+26
2017-08-01Fix the Solaris pthread_t raw type in std to match what's in libcDanek Duvall-1/+1
The old type causes failures when building cargo 0.20.0 after changeset 8304e06b5 in the libc repo.
2017-04-20Add x86_64-linux-android targetMarco A L Barbosa-0/+63
2017-03-29Improve os::linux documentation (#29367)Camille TJHOA-0/+19
2017-03-25Fix c_char (u8 -> i8) definition for i686-linux-androidMarco A L Barbosa-4/+6
2017-03-12Update usages of 'OSX' (and other old names) to 'macOS'.Corey Farwell-2/+2
As of last year with version 'Sierra', the Mac operating system is now called 'macOS'.
2017-01-29Fix a few impl stability attributesOliver Middleton-1/+1
The versions show up in rustdoc.
2016-12-30sparc64-linux supportJorge Aparicio-6/+3
2016-12-20Fix compile errors and suchAlex Crichton-2/+2
2016-12-18Implement `fmt::Debug` for all structures in libstd.Corey Farwell-1/+11
Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.
2016-11-10Use target_os = redox for cfgJeremy Soller-4/+1
2016-10-31Merge branch 'master' of https://github.com/rust-lang/rust into redoxJeremy Soller-2/+4
2016-10-27Add redox systemJeremy Soller-0/+3
2016-10-24Support for aarch64 architecture on FuchsiaRaph Levien-2/+4
This patch adds support for the aarch64-unknown-fuchsia target. Also updates src/liblibc submodule to include required libc change.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 12:30:28 +0000