summary refs log tree commit diff
path: root/library/std/src/sys/solid/net.rs
AgeCommit message (Collapse)AuthorLines
2023-11-08kmc-solid: Implement `{From,Into}Inner<OwnedFd>` for `Socket`Tomoaki Kawada-2/+23
2023-11-08kmc-solid: Remove `FileDesc`Tomoaki Kawada-115/+43
Removes the private type `std::sys::solid::net::FileDesc`, replacing its only usage in `std::sys::solid::net::Socket` with `std::os::solid::io:: OwnedFd`.
2023-11-08kmc-solid: Replace `{From,Into}Inner<c_int>` impls with `*RawFd` for `Socket`Tomoaki Kawada-17/+13
Follows how other targets are implemented.
2023-10-13Make TCP connect() handle EINTR correctlyDenis Smirnov-4/+7
According to the POSIX standard, if connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to EINTR, but the connection request shall not be aborted, and the connection shall be established asynchronously. If asynchronous connection was successfully established after EINTR and before the next connection attempt, OS returns EISCONN that was handled as an error before. This behavior is fixed now and we handle it as success. The problem affects MacOS users: Linux doesn't return EISCONN in this case, Windows connect() can not be interrupted without an old-fashoin WSACancelBlockingCall function that is not used in the library. So current solution gives connect() as OS specific implementation.
2023-09-01kmc-solid: Refactor `is_interrupted` to avoid integer overflowTomoaki Kawada-2/+1
2023-08-25Add a new helper to avoid calling io::Error::kindBen Kimock-0/+6
2023-05-01Inline AsInner implementationsKonrad Borowski-0/+2
2023-04-11kmc-solid: Implement `Socket::read_buf`Tomoaki Kawada-6/+17
2022-08-01kmc-solid: Adapt to a recent change in the `IntoInner` impl of `SocketAddr`Tomoaki Kawada-2/+2
`(x: SocketAddr).into_inner()` evaluates to `(SocketAddrCRepr, socklen_t)` instead of `(*const sockaddr, socklen_t)` as of commit 55e23db13.
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-1/+1
This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
2022-02-04Hide Repr details from io::Error, and rework `io::Error::new_const`.Thom Chiovoloni-5/+5
2022-01-28kmc-solid: Implement `FileDesc::duplicate`Tomoaki Kawada-1/+1
2021-09-28Add SOLID targetsTomoaki Kawada-0/+469
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/
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 20:10:42 +0000