`u32` struct fields in place of file descriptors

[arctic-alpaca]

Hi,

I noticed that three structs use u32 instead of file descriptors. This fits their definition in the kernel but seems like a break with the crates goal of using OwnedFd/BorrowedFd/AsFd/RawFd.

Affected structs I found:

• https://github.com/bytecodealliance/rustix/blob/main/src/net/types.rs#L1524 (I added this blindly following the kernel definition)
• https://github.com/bytecodealliance/rustix/blob/main/src/io_uring.rs#L1205
• https://github.com/bytecodealliance/rustix/blob/main/src/process/prctl.rs#L756

Is this intentional?

[sunfishcode]

In the SocketAddrXdp case, it's not intentional. I didn't realize that SocketAddrXdp's file descriptor field means that any function that "dereferences" it would need to be unsafe, like sendto_xdp and sendto_any. That's also the case for io_uring_params and io_uring_setup too. So those are bugs. I'm not yet sure what to do about them.

For PrctlMmMap, the only user is configure_virtual_memory_map, and it's in the category of things where we can't practically describe the lifetime, so we just make it unsafe. We do a similar thing for kevent.

[arctic-alpaca]

For SocketAddrXdp, the sendmsg and recvmsg implementations in the kernel currently don't make use of the file descriptor or SocketAddrXdp in general. Only the msghdr, in particular the flag(s) (MSG_DONTWAIT) is used. The AF_XDP docs also show an example for sendto(...) with the sockaddr parameter set to NULL.

As far as I can tell, SocketAddrXdp is only used in the bind method to signal the usage of a shared UMEM.

Could the sendto_xdp, sendto_any (and probably recvmsg too) methods just omit SocketAddrXdp?