about summary refs log tree commit diff
path: root/library/std/src/os
AgeCommit message (Collapse)AuthorLines
2021-10-10Add #[must_use] to core and std constructorsJohn Kugelman-0/+1
2021-10-05Suppress some cfg from being shown in the stdlib docsWim Looman-0/+8
2021-09-28Add SOLID targetsTomoaki Kawada-0/+173
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-09-21Rollup merge of #89114 - dequbed:c-char, r=yaahcthe8472-1/+1
Fixes a technicality regarding the size of C's `char` type Specifically, ISO/IEC 9899:2018 — better known as "C18" — (and at least C11, C99 and C89) do not specify the size of `byte` in bits. Section 3.6 defines "byte" as "addressable unit of data storage" while section 6.2.5 ("Types") only defines "char" as "large enough to store any member of the basic execution set" giving it a lower bound of 7 bit (since there are 96 characters in the basic execution set). With section 6.5.3.4 paragraph 4 "When sizeof is applied to an operant that has type char […] the result is 1" you could read this as the size of `char` in bits being defined as exactly the same as the number of bits in a byte but it's also valid to read that as an exception. In general implementations take `char` as the smallest unit of addressable memory, which for modern byte-addressed architectures is overwhelmingly 8 bits to the point of this convention being completely cemented into just about all of our software. So is any of this actually relevant at all? I hope not. I sincerely hope that this never, ever comes up. But if for some reason a poor rustacean is having to interface with C code running on a Cray X1 that in 2003 is still doing word-addressed memory with 64-bit chars and they trust the docs here blindly it will blow up in her face. And I'll be truly sorry for her to have to deal with … all of that.
2021-09-20Auto merge of #88321 - glaubitz:m68k-linux, r=wesleywiserbors-0/+1
Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.
2021-09-20Fix a technicality regarding the size of C's `char` typeNadja Reitzenstein-1/+1
Specifically, ISO/IEC 9899:2018 — better known as "C18" — (and at least C11, C99 and C89) do not specify the size of `byte` in bits. Section 3.6 defines "byte" as "addressable unit of data storage" while section 6.2.5 ("Types") only defines "char" as "large enough to store any member of the basic execution set" giving it a lower bound of 7 bit (since there are 96 characters in the basic execution set). With section 6.5.3.4 paragraph 4 "When sizeof is applied to an operant that has type char […] the result is 1" you could read this as the size of `char` in bits being defined as exactly the same as the number of bits in a byte but it's also valid to read that as an exception. In general implementations take `char` as the smallest unit of addressable memory, which for modern byte-addressed architectures is overwhelmingly 8 bits to the point of this convention being completely cemented into just about all of our software. So is any of this actually relevant at all? I hope not. I sincerely hope that this never, ever comes up. But if for some reason a poor rustacean is having to interface with C code running on a Cray X1 that in 2003 is still doing word-addressed memory with 64-bit words and they trust the docs here blindly it will blow up in her face. And I'll be truly sorry for her to have to deal with … all of that.
2021-09-19Rollup merge of #89051 - schctl:master, r=jyn514Yuki Okushi-15/+60
Add intra-doc links and small changes to `std::os` to be more consistent I believe that a few items in `std::os` should be linked. I've also added a basic example in `std::os::windows`.
2021-09-17modify std::os docs to be more consistentSachin Cherian-15/+60
> add intra doc links > add a usage example for the os::windows module
2021-09-17Rollup merge of #88953 - joshtriplett:chown, r=dtolnayGuillaume Gomez-0/+70
Add chown functions to std::os::unix::fs to change the owner and group of files This is a straightforward wrapper that uses the existing helpers for C string handling and errno handling. Having this available is convenient for UNIX utility programs written in Rust, and avoids having to call unsafe functions like `libc::chown` directly and handle errors manually, in a program that may otherwise be entirely safe code. In addition, these functions provide a more Rustic interface by accepting appropriate traits and using `None` rather than `-1`.
2021-09-17libstd: Add m68k for raw type definitions on LinuxJohn Paul Adrian Glaubitz-0/+1
2021-09-15Add tracking issue for unix_chownJosh Triplett-3/+3
2021-09-14Add chown functions to std::os::unix::fs to change the owner and group of filesJosh Triplett-0/+70
This is a straightforward wrapper that uses the existing helpers for C string handling and errno handling. Having this available is convenient for UNIX utility programs written in Rust, and avoids having to call unsafe functions like `libc::chown` directly and handle errors manually, in a program that may otherwise be entirely safe code. In addition, these functions provide a more Rustic interface by accepting appropriate traits and using `None` rather than `-1`.
2021-09-13Move fortanix module position in std::os reexports for alpha sortGuillaume Gomez-20/+34
2021-09-13Remove usage of cfg_if in std/src/os/mod.rsGuillaume Gomez-31/+71
2021-09-13Simplify std::os module reexports to fix rustdoc linking issuesGuillaume Gomez-109/+74
2021-09-04Document when to use Windows' `symlink_dir` vs. `symlink_file`Chris Denton-2/+20
It was previously unclear which should be used when.
2021-09-02Rollup merge of #88177 - joshtriplett:stabilize-chroot, r=m-ou-seMara Bos-2/+1
Stabilize std::os::unix::fs::chroot I've verified that this works as documented, and I've tested it in (a nightly build of) production software as a replacement for an unsafe call to `libc::chroot`. It's been available in nightly for a few releases. I think it's ready to stabilize. --- Tracking issue: https://github.com/rust-lang/rust/issues/84715
2021-08-25Reference tracking issueThom Chiovoloni-2/+2
2021-08-25Add `c_size_t` and `c_ssize_t` to `std::os::raw`.Thom Chiovoloni-0/+14
2021-08-23Rollup merge of #88230 - steffahn:a_an, r=oli-obkMara Bos-3/+3
Fix typos “a”→“an” Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an. While automation was used to find these, every change was checked manually. Changes in submodules get separate PRs: * https://github.com/rust-lang/stdarch/pull/1201 * https://github.com/rust-lang/cargo/pull/9821 * https://github.com/rust-lang/miri/pull/1874 * https://github.com/rust-lang/rls/pull/1746 * https://github.com/rust-analyzer/rust-analyzer/pull/9984 _folks @ rust-analyzer are fast at merging…_ * https://github.com/rust-analyzer/rust-analyzer/pull/9985 * https://github.com/rust-analyzer/rust-analyzer/pull/9987 * https://github.com/rust-analyzer/rust-analyzer/pull/9989 _For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._ <hr> This has some overlap with #88226, but neither is a strict superset of the other. If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
2021-08-22Remove redundant conversions.Dan Gohman-2/+2
2021-08-22Fix typos “a”→“an”Frank Steffahn-3/+3
2021-08-21Implement `AsFd` etc. for `UnixListener`.Dan Gohman-1/+25
Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for `UnixListener`. This is a follow-up to #87329.
2021-08-19Stabilize std::os::unix::fs::chrootJosh Triplett-2/+1
2021-08-19Fix doc test failures on Windows.Dan Gohman-1/+7
2021-08-19Factor out a common `RawFd`/`AsRawFd`/etc for Unix and WASI.Dan Gohman-490/+286
2021-08-19Fix syntax for non-doc comments, and use `crate::` instead of `std::`.Dan Gohman-6/+6
2021-08-19Add I/O safety trait impls for process::Stdio and process::Child.Dan Gohman-2/+36
2021-08-19Update PidFd for the new I/O safety APIs.Dan Gohman-4/+22
2021-08-19Rename OptionFileHandle to HandleOrInvalid and make it just wrap an ↵Dan Gohman-80/+38
Option<OwnedHandle> The name (and updated documentation) make the FFI-only usage clearer, and wrapping Option<OwnedHandle> avoids the need to write a separate Drop or Debug impl. Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-08-19Don't encourage migration until io_safety is stablized.Dan Gohman-7/+8
2021-08-19Factor out Unix and WASI fd code into a common module.Dan Gohman-560/+298
2021-08-19Synchronize minor differences between Unix and WASI implementations.Dan Gohman-7/+9
2021-08-19Add more comments about the `INVALID_HANDLE_VALUE` situation.Dan Gohman-12/+30
2021-08-19Fix copypasta of "Unix" within the WASI directory.Dan Gohman-1/+1
2021-08-19Reword the description of dup2/dup3.Dan Gohman-1/+1
2021-08-19Add Safety comments to the `As*` for `Owned*` implementations.Dan Gohman-0/+12
2021-08-19Add Owned*, Borrowed*, and As* to the preludes.Dan Gohman-4/+7
2021-08-19Rename `OwnedFd`'s private field to match it's debug output.Dan Gohman-85/+86
2021-08-19Delete a spurious empty comment line.Dan Gohman-1/+0
2021-08-19Add a comment about how `OwnedHandle` should not be used with registry handles.Dan Gohman-2/+15
2021-08-19Add a comment about `OptionFileHandle`.Dan Gohman-0/+4
2021-08-19Be more precise about `mmap` and undefined behavior.Dan Gohman-3/+3
`mmap` doesn't *always* cause undefined behavior; it depends on the details of how you use it.
2021-08-19Add a test to ensure that RawFd is the size we assume it is.Dan Gohman-0/+30
2021-08-19Update library/std/src/os/windows/io/socket.rsDan Gohman-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-08-19Update library/std/src/os/windows/io/handle.rsDan Gohman-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-08-19Update library/std/src/os/unix/io/fd.rsDan Gohman-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-08-19I/O safety.Dan Gohman-153/+1569
Introduce `OwnedFd` and `BorrowedFd`, and the `AsFd` trait, and implementations of `AsFd`, `From<OwnedFd>` and `From<T> for OwnedFd` for relevant types, along with Windows counterparts for handles and sockets. Tracking issue: - <https://github.com/rust-lang/rust/issues/87074> RFC: - <https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md>
2021-08-18Rollup merge of #88012 - sunfishcode:sunfishcode/wasi-raw-fd-c-int, ↵Guillaume Gomez-7/+14
r=alexcrichton Change WASI's `RawFd` from `u32` to `c_int` (`i32`). WASI previously used `u32` as its `RawFd` type, since its "file descriptors" are unsigned table indices, and there's no fundamental reason why WASI can't have more than 2^31 handles. However, this creates myriad little incompability problems with code that also supports Unix platforms, where `RawFd` is `c_int`. While WASI isn't a Unix, it often shares code with Unix, and this difference made such shared code inconvenient. #87329 is the most recent example of such code. So, switch WASI to use `c_int`, which is `i32`. This will mean that code intending to support WASI should ideally avoid assuming that negative file descriptors are invalid, even though POSIX itself says that file descriptors are never negative. This is a breaking change, but `RawFd` is considerd an experimental feature in [the documentation]. [the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html r? `@alexcrichton`
2021-08-13Change WASI's `RawFd` from `u32` to `c_int` (`i32`).Dan Gohman-7/+14
WASI previously used `u32` as its `RawFd` type, since its "file descriptors" are unsigned table indices, and there's no fundamental reason why WASI can't have more than 2^31 handles. However, this creates myriad little incompability problems with code that also supports Unix platforms, where `RawFd` is `c_int`. While WASI isn't a Unix, it often shares code with Unix, and this difference made such shared code inconvenient. #87329 is the most recent example of such code. So, switch WASI to use `c_int`, which is `i32`. This will mean that code intending to support WASI should ideally avoid assuming that negative file descriptors are invalid, even though POSIX itself says that file descriptors are never negative. This is a breaking change, but `RawFd` is considerd an experimental feature in [the documentation]. [the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-22 19:05:19 +0000