linux: Qdd sockaddr_iucv by clayton615 · Pull Request #5041 · rust-lang/libc

clayton615 · 2026-04-02T19:20:40Z

This adds the sockaddr_iucv define in netiucv/iucv. It is primarily used on the s390x platform when linux is running under z/VM, but is present on all the linux systems I've been able to test on.

Description

Adds support for sockaddr_iucv

Sources

https://github.com/torvalds/linux/blob/5619b098e2fbf3a23bf13d91897056a1fe238c6d/include/net/iucv/iucv.h

Checklist

Relevant tests in libc-test/semver have been updated
No placeholder or unstable values like *LAST or *MAX are
included (see #3131)
Tested locally (cd libc-test && cargo test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

clayton615 · 2026-04-02T20:22:46Z

I blocked all of 32bit PPC, it's only missing on ppc32le apparently, but since IUCV is only really useful on s390x I think it's fine. Everywhere else, the kernel headers exist, so I don't think it hurts to include it.

clayton615 · 2026-04-02T20:40:57Z

Nevermind, I'm realizing I have no clue how to tell what archs have the header vs which don't. I know I want it on s390x to work, and at least x86 so that rust analyzer won't scream while I'm writing code around it.

clayton615 · 2026-04-02T22:29:10Z

Huzzah, all tests pass and I think I've done this all correctly.
Apologies for the churn, if you're thinking "This guy has no clue what he's doing" you're right, this is my first contribution to any project.
Let me know if I've done anything wrong or need to change something.

tgross35 · 2026-04-04T09:10:22Z

+    if #[cfg(all(
+        any(target_arch = "x86_64", target_arch = "s390x"),
+        not(any(target_env = "musl", target_os = "android"))
+    ))] {
+        s! {
+            pub struct sockaddr_iucv {


Put this in linux_like/linux/gnu; currently this is available on theoretical emscripten and l4re targets which I think probably doesn't make sense. I think you may also be able to drop the target_arch list too if you do that, and just leave it enabled everywhere.

(test config will need to be updated to match)

Okay, I'll try it under linux/gnu and see if the tests pass. Thanks.

tgross35 · 2026-04-04T09:11:01Z

+                pub siucv_family: crate::sa_family_t,
+                pub siucv_port: crate::in_port_t,
+                pub siucv_addr: crate::in_addr_t,
+                pub siucv_nodeid: [c_char; 8],
+                pub siucv_user_id: [c_char; 8],
+                pub siucv_name: [c_char; 8],


Per https://github.com/torvalds/linux/blob/7ca6d1cfec80ebe46cc063f3284c5896c344d9a1/include/net/iucv/af_iucv.h#L46-L50 all except for the first field are reserved. Does common access require using them or could we make them private in case things change?

Port and Addr don't do anything as far as I know. Making them private should be fine. NodeID and UserID are used to specify your target z/VM ID to connect to, and Name is the application. However, my basic understanding of the C code is that NodeID is actually unused in the linux implementation, so I don't know if the right thing to do is make it private or leave it public in the hopes that some day it's fixed.

In other words, at least UserID and Name should be public. I'll defer to experience on NodeID.

If you don't know of port and addr to do anything and they have a "reserved" comment, would you mind making them private? It's nice to be on the conservative side here because a private field also makes the struct effectively non-exhaustive so we can add fields in the future (just using #[non_exhaustive] would be great but it has a bug currently). And it's easy enough to undo that if we do need them on the future.

clayton615 · 2026-04-04T21:38:36Z

Looks like even when restricted to gnu, it still isn't present on 32bit systems. I'll update it to only look for 64bit.

clayton615 · 2026-04-05T14:56:05Z

Can I just do #[cfg(target_pointer_width = "64)] under here? Or should I add it under ./b64/mod.rs? I'm trying to be tidy and follow conventions, but I'm not sure how best proceed.

tgross35 · 2026-04-08T04:59:06Z

Can I just do #[cfg(target_pointer_width = "64)] under here? Or should I add it under ./b64/mod.rs? I'm trying to be tidy and follow conventions, but I'm not sure how best proceed.

It's much appreciated! Sorry things are a bit confusing. Based on this, moving to b64 would be best here. I'd also be okay just making this s390x-only (src/unix/linux_like/linux/gnu/b64/s390x.rs) to avoid any questions, since that seems to be the only one glibc accounts for https://github.com/search?q=repo%3Abminor%2Fglibc%20%2Fiucv.h%2F&type=code: up to you if you think it's useful on other platforms. I also can't seem to figure out from looking at source why the header would be 64-bit-only.

We have a new structure at src/new that's intended to closer match the source and should hopefully make this all less confusing going forward.

tgross35 · 2026-04-08T04:59:19Z

Also the CI failure should be fixed if you can rebase.

clayton615 · 2026-04-15T19:25:54Z

Whoops, was just trying to rebase, didn't mean to push changes yet. I need more practice with git. Since I'm hear, if I make the fields siucv_port and siucv_addr private, it causes the tests from cargo test to fail. Should I be trying to edit those as well to not do whatever it is that it's doing on them?

tgross35 · 2026-04-16T04:48:49Z

Mind posting the failure? I think things should work. But if making them private turns out to be more effort than it's worth, feel free to just leave them as-is 🙂

clayton615 · 2026-04-16T13:39:04Z

There's about 10 or so errors, all like the following:

   Compiling libc-test v0.1.0 (/home/clayton/Documents/Source/libc/libc-test)
error[E0616]: field `siucv_port` of struct `libc::sockaddr_iucv` is private
      --> /home/clayton/Documents/Source/libc/target/debug/build/libc-test-85dc5bd74a0d5163/out/ctest_output.rs:142987:55
       |
142987 |         let ty_ptr = unsafe { &raw const (*uninit_ty).siucv_port   };
       |                                                       ^^^^^^^^^^ private field

error[E0616]: field `siucv_port` of struct `libc::sockaddr_iucv` is private
      --> /home/clayton/Documents/Source/libc/target/debug/build/libc-test-85dc5bd74a0d5163/out/ctest_output.rs:142993:46
       |
142993 |         check_same(offset_of!(sockaddr_iucv, siucv_port) as u64, ctest_field_offset,
       |                                              ^^^^^^^^^^ private field

I'm going to be honest, I'm not really looking through the test code. Since it picked up my changes and started testing them, I was hoping that was enough. If I should be digging through them and making changes there too, let me know, but honestly since it's clearly running some tests against my new struct I was hoping that was "good enough".

clayton615 · 2026-05-20T18:41:25Z

Looks like all the tests are passing and I think I've rebased correctly. Is there any additional action necessary on my end to move this forward?

clayton615 · 2026-05-27T21:47:57Z

@tgross35 sorry to pester, but I need to know if any additional action is required from me.
I realized I let it sit for a while but I'm still trying to drive this forward as I can.

JohnTitor · 2026-06-14T05:02:27Z

@clayton615 You need to use Padding to make the fields private, see other structs for examples.
Also please actually rebase and squash commits into one instead of merging.

@rustbot author

rustbot · 2026-06-14T05:02:31Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2026-06-16T20:26:23Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

clayton615 · 2026-06-16T20:28:17Z

I'm still pretty new at all of this, but I think I've done what you asked. It looks like it's squashed into one commit, and I rebased on Main. I've also used padding on the two unused fields. Can someone confirm this is correct? Thanks for all of your patience while I'm learning.

clayton615 · 2026-06-17T13:28:04Z

Why did the android test just cancel itself? I don't see any obvious error in the log... Is there a way for me to restart it without having to push another commit?

This adds the sockaddr_iucv define in netiucv/iucv. It is primarily used on the s390x platform when linux is running under z/VM, but is present on all the linux systems I've been able to test on. [ cleaned up commit message - Trevor ]

tgross35

Android CI is unfortunately flaky, see #4297. But this should be good, thank you for the updates!

I pushed your branch to clean up the commit message, the fixup messages that aren't relevant to the final patch don't need to be kept around. (If using interactive rebase, f/fixup rather than s/squash is probably what you actually want).

View changes since this review

clayton615 · 2026-06-18T13:18:20Z

Thanks everyone. Will this also trickle into 0.2? Most packages rely on that branch, so I'm hoping it can be added there. I did mark it for stable nominated, so just checking if it will happen or not.

tgross35 · 2026-06-18T18:49:13Z

It will, the stable-nominated label means it will get picked up in the next backport round

This adds the sockaddr_iucv define in netiucv/iucv. It is primarily used on the s390x platform when linux is running under z/VM, but is present on all the linux systems I've been able to test on. [ cleaned up commit message - Trevor ] (backport <rust-lang/libc#5041>) (cherry picked from commit 7a0c435)

rustbot added S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Apr 2, 2026

tgross35 reviewed Apr 4, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-review label Jun 14, 2026

rustbot added the S-waiting-on-author label Jun 14, 2026

Eragon615 force-pushed the main branch from 9b47548 to 7b7d50d Compare June 16, 2026 20:26

tgross35 force-pushed the main branch from 7b7d50d to d8fbab2 Compare June 18, 2026 01:33

linux: add sockaddr_iucv

e5c608e

This adds the sockaddr_iucv define in netiucv/iucv. It is primarily used on the s390x platform when linux is running under z/VM, but is present on all the linux systems I've been able to test on. [ cleaned up commit message - Trevor ]

tgross35 force-pushed the main branch from d8fbab2 to e5c608e Compare June 18, 2026 01:33

tgross35 approved these changes Jun 18, 2026

View reviewed changes

tgross35 enabled auto-merge June 18, 2026 01:35

tgross35 added this pull request to the merge queue Jun 18, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 18, 2026

tgross35 added this pull request to the merge queue Jun 18, 2026

Merged via the queue into rust-lang:main with commit 7a0c435 Jun 18, 2026
52 checks passed

rustbot mentioned this pull request Jun 18, 2026

RFC 2292 struct and constant definitions #4954

Draft

3 tasks

tgross35 changed the title ~~adds sockaddr_iucv~~ linux: Qdd sockaddr_iucv Jun 18, 2026

tgross35 mentioned this pull request Jun 23, 2026

[0.2] Backports #5207

Merged

tgross35 added stable-applied This PR has been cherry-picked to libc's stable release branch and removed stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Jun 23, 2026

Uh oh!

Conversation

clayton615 commented Apr 2, 2026

Description

Sources

Checklist

Uh oh!

clayton615 commented Apr 2, 2026

Uh oh!

clayton615 commented Apr 2, 2026

Uh oh!

clayton615 commented Apr 2, 2026

Uh oh!

tgross35 Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clayton615 Apr 4, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clayton615 Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

clayton615 commented Apr 4, 2026

Uh oh!

clayton615 commented Apr 5, 2026

Uh oh!

tgross35 commented Apr 8, 2026

Uh oh!

tgross35 commented Apr 8, 2026

Uh oh!

clayton615 commented Apr 15, 2026

Uh oh!

tgross35 commented Apr 16, 2026

Uh oh!

clayton615 commented Apr 16, 2026

Uh oh!

This comment has been minimized.

clayton615 commented May 20, 2026

Uh oh!

clayton615 commented May 27, 2026

Uh oh!

JohnTitor commented Jun 14, 2026

Uh oh!

rustbot commented Jun 14, 2026

Uh oh!

rustbot commented Jun 16, 2026

Uh oh!

clayton615 commented Jun 16, 2026

Uh oh!

clayton615 commented Jun 17, 2026

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

clayton615 commented Jun 18, 2026

Uh oh!

tgross35 commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tgross35 Apr 4, 2026 •

edited

Loading

tgross35 Apr 4, 2026 •

edited

Loading

clayton615 Apr 4, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading