about summary refs log tree commit diff
path: root/library/std/src/sys/itron
AgeCommit message (Collapse)AuthorLines
2024-01-11std: begin moving platform support modules into `pal`joboet-1497/+0
2023-08-25Add a new helper to avoid calling io::Error::kindBen Kimock-0/+5
2023-03-03Match unmatched backticks in library/est31-1/+1
2023-02-16Rollup merge of #106372 - joboet:solid_id_parking, r=m-ou-seDylan DPC-72/+37
Use id-based thread parking on SOLID By using the [`slp_tsk`/`wup_tsk`](https://cs.uwaterloo.ca/~brecht/courses/702/Possible-Readings/embedded/uITRON-4.0-specification.pdf) system functions instead of an event-flag structure, `Parker` becomes cheaper to construct and SOLID can share the implementation used by NetBSD and SGX. ping ``@kawadakk`` r? ``@m-ou-se`` ``@rustbot`` label +T-libs
2023-01-14Remove various double spaces in source comments.André Vennberg-1/+1
2022-12-31std: use id-based thread parking on SOLIDjoboet-72/+37
2022-12-12kmc-solid: Synchronize with the read when sending a joining task ID to a joineeTomoaki Kawada-1/+8
2022-12-12kmc-solid: Synchronize the first update of `ThreadInner::lifecycle` with the ↵Tomoaki Kawada-8/+8
second one on detach The first update (swap RMW operation) must happen-before the second update so that the latter can release `ThreadInner` safely.
2022-12-02kmc-solid: Don't do `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`Tomoaki Kawada-18/+30
This pattern seems to be considered illegal by Miri.
2022-12-01kmc-solid: Address compiler warningsTomoaki Kawada-3/+3
Addresses the warn-by-default lints `unused_imports` and `unused_unsafe`.
2022-12-01kmc-solid: Use `expose_addr` and `from_exposed_addr` for pointer-integer castsTomoaki Kawada-2/+2
Pointer-integer casts are required for conversion between `EXINF` (ITRON task entry point parameter) and `*const ThreadInner`. Addresses the deny-level lint `fuzzy_provenance_casts`.
2022-11-06std: remove lock wrappers in `sys_common`joboet-11/+4
2022-09-03std: make `ReentrantMutex` movable and `const`; simplify `Stdout` initializationjoboet-6/+0
2022-06-26Rollup merge of #97140 - joboet:solid_parker, r=m-ou-seMatthias Krüger-3/+117
std: use an event-flag-based thread parker on SOLID `Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after #96393, are SOLID, SGX and Hermit (more PRs coming soon). SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable. I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API). `````@kawadakk````` I assume you are the target maintainer? Could you test this for me?
2022-06-06Make all {Mutex, Condvar, RwLock}::new #[inline].Mara Bos-0/+1
2022-06-03Use Drop instead of destroy() for locks.Mara Bos-3/+3
2022-05-19std: fix deadlock in `Parker`joboet-4/+9
2022-05-18std: use an event flag based thread parker on SOLIDjoboet-3/+112
2022-05-09Use Rust 2021 prelude in std itself.Mara Bos-3/+1
2022-04-16Use a single ReentrantMutex implementation on all platforms.Mara Bos-93/+0
2022-03-22Move std::sys::{mutex, condvar, rwlock} to std::sys::locks.Mara Bos-1/+1
2022-02-13make Instant::{duration_since, elapsed, sub} saturating and remove workaroundsThe8472-9/+0
This removes all mutex/atomics based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Effectively this moves the monotonization from `Instant` construction to the comparisons. This has some observable effects, especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic. This may hide some programming errors until someone actually looks at the resulting `Duration` * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. The upside is reduced complexity and lower overhead of `Instant::now`.
2022-02-10kmc-solid: Wait queue should be sorted in the descending order of task ↵Tomoaki Kawada-1/+1
priorities In ITRON, lower priority values mean higher priorities.
2022-02-10kmc-solid: Fix wait queue manipulation errors in the `Condvar` implementationTomoaki Kawada-3/+8
2022-01-31Rollup merge of #93504 - solid-rs:fix-kmc-solid-stack-size, r=nagisaEric Huss-1/+2
kmc-solid: Increase the default stack size This PR increases the default minimum stack size on the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets to 64KiB (Arm) and 128KiB (AArch64). This value was chosen as a middle ground between supporting a relatively complex program (e.g., an application using a full-fledged off-the-shelf web server framework) with no additional configuration and minimizing resource consumption for the embedded platform that doesn't support lazily-allocated pages nor over-commitment (i.e., wasted stack spaces are wasted physical memory). If the need arises, the users can always set the `RUST_MIN_STACK` environmental variable to override the default stack size or use the platform API directly.
2022-01-31kmc-solid: Increase the default stack sizeTomoaki Kawada-1/+2
2022-01-31kmc-solid: Inherit the calling task's base priority in `Thread::new`Tomoaki Kawada-5/+2
Fixes a spawned task getting an unexpectedly higher priority if it's spawned by a task whose priority is temporarily boosted by a priority- protection mutex.
2021-12-14Fix a bunch of typosFrank Steffahn-2/+2
2021-11-01itron: Rename `itron::thread::{available_conccurrency -> available_parallelism}`Tomoaki Kawada-1/+1
Catching up with commit b4615b5bf9e3e722b480190714ad44ecd7fa2ed1
2021-09-28Add SOLID targetsTomoaki Kawada-0/+1507
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/