[BUG] Socket option renumbering in #20713 breaks Rust's libc
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- networking
调研方向
Start by comparing the socket option constants in Rust's src/unix/nuttx/mod.rs with the NuttX master headers, as the report identifies 29 mismatches after #20713. Read that change and trace the affected socket options, including the TCP/IP/IPv6 values built on them. Determine whether NuttX should preserve the existing ABI values or coordinate a Rust libc update; done means the chosen numbering is consistent and the reported Rust networking calls work.
由索引模型根据 Issue 内容生成。
描述
Description / Steps to reproduce the issue
#20713 renumbered the SOL_SOCKET options and moved __SO_PROTOCOL from 16 to 11, which also shifts the TCP/IP/IPv6 options built on top of it. Rust's libc hardcodes these values for NuttX (src/unix/nuttx/mod.rs) and still has the 13.1.0 ones, so Rust networking will break with the next release.
I diffed every constant in Rust's nuttx/mod.rs against the master headers (sim:nsh). 29 of them don't match, and all are socket options, e.g.:
rust master
SO_REUSEADDR 11 0
SO_ERROR 4 69
SO_RCVBUF 8 64
SO_SNDBUF 12 66
SO_SNDTIMEO 14 11
TCP_NODELAY 16 11
IP_TTL 30 25
IPV6_V6ONLY 23 18
The worst one is TcpListener::bind: Rust std always sets SO_REUSEADDR (11) first, and 11 is now SO_SNDTIMEO, which wants a struct timeval. I checked with a small C program on sim:tcploop using Rust's numbers:
rust SO_REUSEADDR(11): ret=-1 errno=22
rust SO_ERROR(4): ret=-1 errno=92
rust TCP_NODELAY(16): ret=-1 errno=38 (16 is TCP_CORK now)
So any Rust TCP server fails at bind, and set_nodelay / take_error fail too.
Should we keep the new numbering and fix Rust's libc (and say so in the release notes), or keep these values stable since they're user-facing ABI? Happy to send the libc PR either way.
On which OS does this issue occur?
[OS: Linux]
What is the version of your OS?
Ubuntu, kernel 7.0
NuttX Version
master (after #20713)
Issue Architecture
[Arch: all]
Issue Area
[Area: Networking]
Host information
No response
Verification
- I have verified before submitting the report.
- 主要语言
- C
- 星标
- 4.1k
- 派生
- 1.8k
- 平均合并
- 1 天 3 小时
- 30 天内合并 PR
- 833
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/nuttx 的其他 Issue
-
Arch: all Arch: arm Area: Build system OS: Linux Type: Bug
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Arch: all OS: Linux Type: Bug
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
Type: Enhancement
难度 4/5 3-5 天 新手友好度 22/100
维护者通常 1 天内回复
-
Arch: simulator Arch: xtensa Area: Kernel OS: Mac Type: Bug
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
good first issue
难度 2/5 1-3 小时 新手友好度 72/100
dfa1/rocksdb-ffm#292 ·
维护者通常 1 天内回复
-
SPIDevice selects an active-high device as soon as it is created可能已有人在做 @mikeysklar 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 73/100
adafruit/circuitpython#11869 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 78/100
gnif/LookingGlass#1352 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复