-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pr2 move readv/writev to the kernel #87
Merged
Merged
Conversation
This file contains 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
|
Donny9
approved these changes
Dec 26, 2024
currently, nuttx implements readv/writev on the top of read/write. while it might work for the simplest cases, it's broken by design. for example, it's impossible to make it work correctly for files which need to preserve data boundaries without allocating a single contiguous buffer. (udp socket, some character devices, etc) this change is a start of the migration to a better design. that is, implement read/write on the top of readv/writev. to avoid a single huge change, following things will NOT be done in this commit: * fix actual bugs caused by the original readv-based-on-read design. (cf. apache/nuttx#12674) * adapt filesystems/drivers to actually benefit from the new interface. (except a few trivial examples) * eventually retire the old interface. * retire read/write syscalls. implement them in libc instead. * pread/pwrite/preadv/pwritev (except the introduction of struct uio, which is a preparation to back these variations with the new interface.)
The problem has been inherited from the original libc readv/writev implementation. However, now it's exposed in more situations because this implemenation is used to back read/write as well. I expect this fixes the regressions observed on the Espressif CI. apache/nuttx#13498 (comment) Note that, even with this fix, these "compat" readv/writev implementations are still inheritedly broken. (E.g. consider that a data boundary happens to match one of iovec boundaries) However, this fix is enough for read/write, where iovcnt is always 1.
Most tools used for compliance and SBOM generation use SPDX identifiers This change brings us a step closer to an easy SBOM generation. Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
xiaoxiang781216
approved these changes
Dec 30, 2024
jasonbu
pushed a commit
to jasonbu/vela-nuttx
that referenced
this pull request
Dec 30, 2024
… uio *)' Fix build break after open-vela#87 Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com> Signed-off-by: buxiasen <buxiasen@xiaomi.com>
pengxianghao21
pushed a commit
that referenced
this pull request
Dec 30, 2024
… uio *)' Fix build break after #87 Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com> Signed-off-by: buxiasen <buxiasen@xiaomi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.