`u32` struct fields in place of file descriptors
arctic-alpaca opened this issue · 2 comments
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?
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.
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?