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]

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]

From #1110 (comment):
epoll appears to be inconsistent in that it expects users to use the module prefix (i.e. epoll::foo) instead of using the free function directly. This is neat, but it's inconsistent with the rest of rustix's APIs: inotify, port, eventfd, io_uring, mount, shm, and probably others I didn't have time to look at. @sunfishcode thoughts on a PR that restores the epoll_ prefix with some deprecations? We could go the other direction, but that interacts poorly with auto-complete and would be much more breaking so not worth it IMO.

Sidenote: the deprecations won't actually work due to rust-lang/rust#30827. (For example the fs::*mount APIs are deprecated but there's no warning about it.)

[SUPERCILEX]

I haven't yet made this change. I do like how it makes the interface clearer, but I'm unsure about the range check it introduces.

By this do you mean that we're limiting possible inputs the caller can supply (namely no negative numbers). I feel like that's reasonable as we probably want a different API if negative numbers start meaning something else.

---

I'd really like to see the story around MaybeUninit buffers resolved for 1.0 (or a clear expectation that there will be a 2.0 addressing the issue). I'm still on team dependent types (as in the input to the function determines the return type), but I'm not sure how we should hash this out.

[SUPERCILEX]

we should just go all the way to Option and use ppoll

If we can, that sounds even better!

---

Yup, mostly #1110 as I think it could have ripple effects (e.g. getting rid of io::read_uninit).

[sunfishcode]

we should just go all the way to Option and use ppoll

If we can, that sounds even better!

I've now filed #1285 to do that.

Yup, mostly #1110 as I think it could have ripple effects (e.g. getting rid of io::read_uninit).

I've now filed #1290 starting to prototype something.

[sunfishcode]

I've now published rustix 1.0.0-prerelease.0. For anyone following this issue, please test it out and report any findings!

I've documented all the API changes I'm aware of here; please let me know if anything there is unclear or if there's something not covered.

A potential change that hasn't landed yet is #1290. It's mostly a backwards-compatible change, however it is technically an API break because in some cases it requires users add a &mut *. If that change lands, I'll plan to do another prerelease before the final release.