Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify inotify public interface across backends and accept impl AsFd #1105

Merged
merged 2 commits into from
Aug 15, 2024

Conversation

SUPERCILEX
Copy link
Contributor

It currently only accepts a BorrowedFd which is annoying. Pretty sure this is a backwards compatible change.

@SUPERCILEX SUPERCILEX changed the title Unify inotify public interface across backends Unify inotify public interface across backends and accept impl AsFd Aug 14, 2024
@@ -24,12 +24,12 @@ pub fn inotify_init(flags: CreateFlags) -> io::Result<OwnedFd> {
/// this method may result in it returning the same watch descriptor. An
/// application should keep track of this externally to avoid logic errors.
#[inline]
pub fn inotify_add_watch<P: crate::path::Arg>(
inot: BorrowedFd<'_>,
pub fn inotify_add_watch<Fd: AsFd, P: crate::path::Arg>(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think adding a generic isn't backwards compatible if someone explicitly specified P. Then again, I don't think anybody uses this code? https://github.com/search?q=inotify_add_watch+language%3ARust+rustix+-is%3Afork&type=code At least not publicly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it by chance work to use <P: crate::path::Arg, Fd: AsFd>?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would complain with a missing generic and you'd have to put an underscore. Maybe we could do impl AsFd and put a todo to make it a generic later?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making it impl AsFd and adding a TODO sounds reasonable to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, done!

Copy link
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a few minor details:

/// application should keep track of this externally to avoid logic errors.
#[inline]
pub fn inotify_add_watch<P: crate::path::Arg>(
inot: impl AsFd,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add the TODO comments about changing this impl AsFd to a generic argument in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #753 (comment). I feel like it'll be more effective to run a global pass on the whole lib rather than trying to remember the spots impls need to be fixed. If you disagree, I'll be happy to add the TODOs here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, makes sense.

/// descriptor from being implicitly passed across `exec` boundaries.
#[doc(alias = "inotify_init1")]
pub fn inotify_init(flags: CreateFlags) -> io::Result<OwnedFd> {
// SAFETY: `inotify_init1` has no safety preconditions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you restore these three SAFETY comments? I know they're not super interesting, but they're there for the benefit of people auditing the code. They record what we believed the relevant safety considerations are, so that if it ever turns out that we missed something, it's easier to understand the intent of the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, restored.

@sunfishcode sunfishcode merged commit 9f57313 into bytecodealliance:main Aug 15, 2024
41 of 43 checks passed
@sunfishcode
Copy link
Member

This is released in rustix 0.38.35.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants