1.0 release planning

[sunfishcode]

Here's a planning issue for a 1.0 release, similar to the one for the 0.38 release. Hopefully we won't need a semver bump for a good long while, but when we do, here's the list of changes we can make:

• Remove the deprecated mount functions in the fs module (details)
• Make the underlying type of rustix::fs::Access consistent between linux_raw and libc backends (Port 1.0-staging to main #1152)
• Rename mount_recursive_bind to mount_bind_recursive? Factor out a new top-level mount module. #763 (comment) (Rename mount_recursive_bind to mount_bind_recursive. #1273)
• Change SeekFrom::Hole and SeekFrom::Data's field from i64 to u64. (Make the offsets for SeekFrom's Hole and Data unsigned. #1266)
• rename Shutdown::ReadWrite to Shutdown::Both to align with std (Rename Shutdown::ReadWrite to Shutdown::Both. #1264)
• remove the features = ["extra_traits"] from the libc dependency (Remove the "libc-extra-traits" feature. #1168)
• move (or perhaps alias?) sched_yield and other sched_* functions from process to thread, since they apply to threads rather than processes on Linux etc. (Move sched_* and membarrier_* into rustix::thread. #1265)
• stx_mtime and similar members of Statx should be i64, because Unix timestamps can be negative.
• futex's first argument should be Atomic
• Remove get_ from sockopt getters, following Rust convention. Consider removing get_ in other things too. (Rename sockopts getters to remove the "get_". #1269)
• The udata argument to rustix::event::kqueue::Event::new should be a pointer instead of an isize in order to better preserve provenance. (Make APIs preserve strict provenance. #1270)
• The stx_attributes_mask field of Statx with flags like libc::STATX_ATTR_MOUNT_ROOT should ideally be a bitflags, which requires making Statx a custom type (which should match layout with libc::statx). (Reorganize Stat, Statx, and SockaddrStorage #1282)
• Rename get_* functions (eg. sockopts) to remove the get_ prefix, which is more idiomatic Rust?
• Rename MountPropagationFlags::SLAVE (Rename a flag in MountPropagationFlags. #1169)
• Rename some of WaitidOptions, WaitidStatus, and/or WaitId to make the capitalization of Id consistent (Rename Waidid* to WaidId*, for consistency with WaitId. #1267)
• Remove the inotify_ prefixes from things in the fs::inotify module.
• Remove the shm_ and Shm prefixes from things in the shm module.
• Figure out a way to do a recv into an uninitialized buffer with the TRUNC flag set (see Fix recv_uninit to handle the TRUNC flag. #1159) (Report the number of received bytes in recv_uninit and recvfrom_uninit. #1278)
• remove rustix::procfs and publish rustix-linux-procfs as the replacement (Remove procfs. #1275)
• remove linux-raw-sys from the public API (Port 1.0-staging to main #1152) (Remove most linux-raw-sys types from the public API #1277) (Reorganize Stat, Statx, and SockaddrStorage #1282)
• change io_uring_register_files_skip from a const fn to a constant. (Replace the io_uring_register_files_skip function with a constant. #1268)

Deferring for now:

• move rustix::thread sleep functions into a new rustix::sleep module, because they're usable from single-threaded programs too
• Move Dir into its own crate, and have rustix export getdents directly?
• Split open and openat into separate functions for "create" which needs a mode vs. "open existing" which doesn't need a mode?
• Make RecvAncillaryBuffer::drain always remove all messages, even if the iterator isn't exhausted. With that, we can remove the read_and_length in AncillaryDrain.
• Replace rustix::cstr! with something like rustix::nativestr! so that users don't hard code "native strings are C strings" in their code?
• rename Arg::as_str to avoid "a method with this name may be added to the standard library in the future" warnings
• rustix::process::waitpid has no way to wait for specific process groups (Pid now requires non-negative values). waitpgid has been added as a temporary workaround.
• remove libc from the public API (Port 1.0-staging to main #1152) (Remove most linux-raw-sys types from the public API #1277)

Don't do these:

• set_ip_add_membership/get_ip_add_membership should take address and ifindex arguments and *_with_ifindex should be removed.
• Rename ClockId::Uptime on FreeBSD to Boottime, since it's an alias

[notgull]

It would be nice to have an uninitialized buffer API for read, recv, recvmsg, etc. That way you could read to completely uninitialized buffers.

[sunfishcode]

Reading into uninitialized buffers is tracked in #81.

[sunfishcode]

I think it makes sense to call the next release 1.0, instead of 0.39.

0.x version numbers are sometimes seen as signifying instability. And, 0.x version numbers don't have an equivalent of minor versions.

The overall plan here can stay the same. 1.0 (formerly 0.39 here) would still be a good long while after 0.38, and a good long while after that would be a 2.0 (instead of a 0.40), and so on.

[notgull]

If this is going to be a stable release, we should make sure that libc and linux-raw-sys aren't exposed in the public API. I know there are still a few places where it is.

In my opinion a stable release is a bad idea, as the API is still somewhat volatile. There should at least be an "unstable" feature flag to test new APIs for inclusion, like Tokio has.

[sunfishcode]

I already consider 0.38 to be stable. For example, I maintain an older version of linux-raw-sys to preserve compatibility with rustix 0.38. And I'm not aware of any significant volatility in the 0.38 API. It's added lots of features, and even deprecated a handful of things, but ideas for breaking changes are collected here in this issue, specifically to keep 0.38 stable.

So my idea for 1.0 is just to better communicate what's already happening.

It would be nice to better encapsulate libc/linux-raw-sys types, and I'm open to adding an "unstable" feature flag if there's a need for it. I'm under the impression that these aren't urgent right now, though I'd be happy to learn more about how these impact users.

[SUPERCILEX]

rustix::cstr! should be removed now that c"..." strings just went stable: rust-lang/rust#117472

[morr0ne]

rustix::cstr! should be removed now that c"..." strings just went stable: rust-lang/rust#117472

This feature will not be available in stable until February 2024, so we probably want to wait for that.

[sunfishcode]

Rustix's MSRV won't support new features like c"..." strings for quite some time, so we'll need to keep cstr! for now.

[SUPERCILEX]

I'd like to propose making the timeout param in https://docs.rs/rustix/latest/rustix/event/fn.poll.html be an Option<u32> where None passes -1 to act as an infinite timeout. That feels like a clearer interface than anything negative is infinity.