Conversation
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.
|
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. |
|
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. |
|
Huzzah, all tests pass and I think I've done this all correctly. |
src/unix/linux_like/mod.rs
Outdated
| if #[cfg(all( | ||
| any(target_arch = "x86_64", target_arch = "s390x"), | ||
| not(any(target_env = "musl", target_os = "android")) | ||
| ))] { | ||
| s! { | ||
| pub struct sockaddr_iucv { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Okay, I'll try it under linux/gnu and see if the tests pass. Thanks.
src/unix/linux_like/mod.rs
Outdated
| 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], |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Looks like even when restricted to gnu, it still isn't present on 32bit systems. I'll update it to only look for 64bit. |
|
Can I just do |
It's much appreciated! Sorry things are a bit confusing. Based on this, moving to We have a new structure at |
|
Also the CI failure should be fixed if you can rebase. |
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
libc-test/semverhave been updated*LASTor*MAXareincluded (see #3131)
cd libc-test && cargo test --target mytarget);especially relevant for platforms that may not be checked in CI
@rustbot label +stable-nominated