Skip to content
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 4 commits into from
Dec 30, 2024
Merged

Conversation

guohao15
Copy link
Contributor

No description provided.

@CLAassistant
Copy link

CLAassistant commented Dec 26, 2024

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 3 committers have signed the CLA.

✅ guohao15
❌ yamt
❌ jerpelea
You have signed the CLA already but the status is still pending? Let us recheck it.

yamt and others added 4 commits December 27, 2024 06:51
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 xiaoxiang781216 merged commit 967d242 into open-vela:dev Dec 30, 2024
1 of 3 checks passed
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants