refactor: change bitwidths of file off tys in l4re#5173
Open
dybucc wants to merge 1 commit into
Open
Conversation
rustbot
added
S-waiting-on-review
stable-nominated
This patch makes a few changes to the file offset types and routines that are made available under the `unix/linux_like/l4re` module. The current upstream definitions often use 64-bit suffixed types instead of their unsuffixed types. Under a default build with unchanged makefile settings, their memory representation is effectively equivalent. The `libc` crate is striving to remove support for suffixed file offset/`time_t`-related types that only serve aliasing purposes in favor of keeping a single, fixed-width, unsuffixed type. This patch does not introduce breaking changes even though entire records have been altogether changed. This is because the currently supported target triples using L4Re in upstream rustc only include `x86_64-unknown-l4re-uclibc`. The "breaking" changes have been made to aarch64-specific types. It is also for this reason that the patch does not introduce further changes regarding the modules where symbols are defined. There are a few records, such as `stat` and `statfs`, which are defined both upstream and in the L4Re forks of musl and uClibc as being equivalent. The current maintainer for this target triple may have other plans, so that has been left unmodified. Finally, and to round up changes submitted in other patches, this patch also deprecates various types in the top-level `unix/linux_like` and `unix/linux_like/linux_l4re_shared` modules. These have been deprecated after a few observations between shared deprecated items among prior patches to platforms whose target environment coincided with one of uClibc, musl or OhOS.
dybucc
force-pushed
the
l4re-file-offsets
branch
from
a64dd66 to
66c2f42
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR deprecates a number of symbols from the
unix/linux_like/l4remodule. This has also come with further deprecations and modifications in other top-level modules.The changes in the target module have been mostly due to requirements for the current definitions in the
libccrate to match solely those of 64-bit file offset/time_t-related types. To this extent, all file offset types and routines have been verified to use their 64-bit types, and the suffixed symbols have been annotated with the corresponding deprecation attribute.These changes and those included in related PRs (#5165 and #5170) meant that other top-level modules under
unix/linux_likecould generally have their 64-bit-suffixed types deprecated. This was included in this patch for all symbols exposed under any target triple whose target environment was one of uClibc, musl or OhOS. Such changes may cause merge conflicts with other open PRs. Those will be resolved in due time (if the changes in this PR is viable.)Testing on the affected L4Re target has not been possible because upstream rustc support for it is broken, as tracked in [1].
Note there have breaking changes in some modules, but this PR has still been marked as targetting the next 0.2 release. Those changes actually live within a module for which there is no official Rust support; Namely, the combination of L4Re as a target OS, uClibc as the target environment, and Aarch64 as the target architecture. In theory, this should not break anybody's code, so long as the rustc does not implement support for this type of L4Re target triple. This has also been the reason why no further code has been restructured under the
l4re/uclibcsubmodule. The current maintainer of that platform seems to be in the process of updating and possibly expanding support to other architectures, so no further changes have been made there.This "breaking" change included redefining the
statstructure under theuclibc/aarch64module, because it seemed to have a mismatched layout to that of upstream l4re-core's uclibc-ng. This change is especiallly prone to removal considering the currently lacking support in rustc.The
l4re/muslsubmodule should correspond with the musl backend for L4Re, but there neither seems to be official Rust target triples whose target OS is L4Re and whose target environment is musl. In this instance, there was not much not to modify, mostly because a large amount of musl symbols are not defined under L4Re (with musl as its libc implementation.)Sources
Sources on the uClibc changes are documented in #5165. A regex search of the affected symbols on l4re-core's
libcdirectory reveals no modifications in their patches would necessitate changes in this patch.Souces on the musl changess are "documented" in #5170. Definitions follow a straightforward and uniform pattern so the sources actually consist of only a regex search in the main worktree.
Sources on OhOS have not been provided because their vendored version of musl seems mostly unchanged from upstream.
Checklist
libc-test/semverhave been updated*LASTor*MAXare included (see #3131)cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI@rustbot label +stable-nominated