Implement I/O Safety

[asomers]

Most Nix functions that involve files use RawFd arguments, but those are difficult to use correctly. For example, it's easy to use-after-close. Rust nightly just added I/O Safety traits that fix most of the problems with RawFd. It's a very good fit for Nix. We should begin using them as soon as possible. They're on track to be released as part of Rust 1.63.0, which will probably be released on 11-August.
https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md

• pty (feat: I/O safety for 'sys/termios' & 'pty' #1921)
• sched (feat: I/O safety for 'sys/uid' & 'sched' #1931)
• poll (feat: I/O safety for 'poll' #1937, Relax lifetime requirements for PollFd::new #2134)
• unistd (refactor: I/O safety for unistd.rs #2440)
• sendfile (feat: I/O safety for 'sys/sendfile' #1926)
• sys/select(feat: I/O safety for 'sys/select' #1940, Relax lifetime requirements for FdSet::{insert, remove, contains} #2136)
• sys/uio (feat: I/O safety for 'sys/uid' & 'sched' #1931)
• sys/termios (feat: I/O safety for 'sys/termios' & 'pty' #1921)
• sys/inotify (feat: I/O safety for 'sys/inotify' #1913)
• sys/wait (feat: I/O safety for 'sys/wait' #1923)
• sys/signalfd (signalfd optional file descriptor #1874)
• sys/event (Rustier kqueue API #1943)
• sys/statvfs (feat: I/O safety for 'sys/statvfs' #1927)
• sys/stat (refactor: I/O safety for sys/stat.rs #2439)
• sys/signal (feat: I/O safety for 'sys/signal' #1936)
• sys/statfs (feat: I/O safety for 'sys/statfs' #1919)
• sys/epoll (Epoll type #1882 )
• sys/eventfd (feat: I/O safety for 'sys/memfd' & 'sys/event' & 'sys/eventfd' #1928)
• sys/aio (Added I/O safety to sys::aio #2401)
• sys/socket/sockopt (Add I/O safety to sockopt and some socket functions #1915)
• sys/timerfd (feat: I/O safety for 'sys/timerfd' #1933)
• sys/socket/addr (Add I/O safety to sockopt and some socket functions #1915)
• sys/socket (Add I/O safety to sockopt and some socket functions #1915)
• sys/mman (Use I/O safety in sys::mman #1916)
• sys/dir (refactor: I/O safety for modules fcntl and dir #2434)
• sys/memfd (feat: I/O safety for 'sys/memfd' & 'sys/event' & 'sys/eventfd' #1928)
• sys/fcntl (refactor: I/O safety for modules fcntl and dir #2434)
• sys/kmod (feat: I/O safety for 'kmod' #1922)
• sys/fanotify (refactor: I/O safety for sys/fanotify.rs #2443)

[polarathene]

• A tracking issue over at io-lifetimes (crate referenced by the linked RFC) may be of interest.
• rustix, a crate similar to nix also implements the new I/O safety traits (via using io-lifetimes) if that's helpful to reference.

I lack the knowledge of how you'd approach this, but the main takeaway from the io-lifetimes tracking issue seems to describe two approaches (with or without the io-lifetimes dependency):

They may require a Minimum Supported Rust Version bump too, though another option is to use io-lifetimes once the change to have it re-export std's types and traits by default lands.

Once bumping MSRV becomes acceptable for the project, you can drop io-lifetimes?

[notgull]

Given that Rust 1.63.0 just dropped and I/O safety is now in the standard library, it might be worth it to bump the MSRV.

If the bump is desired, I can implement the change, moving the input file descriptors to BorrowedFd and the output file descriptors to OwnedFd.

[coolreader18]

I've got a wip branch changing around half so far of the uses of RawFd to the io-safe versions.

[SUPERCILEX]

@coolreader18 Mind trying to merge what you've got? I don't see the need to convert everything at once... any progress in this direction is a net improvement IMO.

[SUPERCILEX]

@asomers I'd be willing to take a crack at this over the weekend assuming there's review bandwidth.

[SUPERCILEX]

I've been thinking about this some more... what's our backwards compat story? Do we add an io_safety feature that has the new wrappers and deprecate all the old ones? Or do we just pull the plug and make everyone use the new types?

cc @rtzoeller

[asomers]

Since we're pre-1.0, we don't technically have to maintain backwards-compat. And in the past, we sometimes haven't. If you were only going to modify one or two functions, I'd say add new methods and deprecate the old ones. But this change is way too big. Better to pull the plug all at once, I'd say.

[notgull]

As it's partially a safety concern, I think a break would be justified, as significant as it would be.

[SUPERCILEX]

Sounds good! Based on discussion over at rustix, I'll need to update my PR to not take fds in by reference. #1862 needs to go through first anyway, so I'll update stuff after that.

Another possibility that's crossed my mind: we could have an extension trait on fds so that you can say fd.read(...). I don't think this is a good idea because it'll be confusing with functions that take in multiple fds, but I wanted to throw it out there.

[asomers]

The extension trait sounds confusing to me, just because it's such a big break from Nix's existing API.