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

Fix kqueue filter consts type on NetBSD [WAS: Provide EV_SET] #787

Merged
merged 1 commit into from
Oct 24, 2017

Conversation

vojtechkral
Copy link
Contributor

@vojtechkral vojtechkral commented Oct 1, 2017

Using BSD kqueue's kevent structure is tedious, because some BSD variants define the structure slightly differently. This forces user's code to differentiate between BSD variants and initialize kevent accordingly, which is annoying and error-prone.

For an example, refer to MIO.

This is an attempt to fix it - provide a ctor function with the same signature across BSD variants.

Is an impl piece for a C structure allowed in libc?

edit: I noticed the kevent function has a similar problem, maybe I should include a fix for that too...
edit: ^ Done

@alexcrichton
Copy link
Member

Thanks for the PR! Right now though this crate does not provide functions like this, this'd be an implementation detail in a downstream crate.

@vojtechkral
Copy link
Contributor Author

vojtechkral commented Oct 4, 2017

Ok, understandable. Are macros out of question too? (Ie. maybe provide an EV_SET equivalent?) If so, I'll just deal with it in my own code, feel free to close this PR if this isn't applicable.

@alexcrichton
Copy link
Member

Nah macros should be fine to add, there's already a number here

@vojtechkral
Copy link
Contributor Author

Allrighty then, I'll refactor the code...

@vojtechkral vojtechkral changed the title Provide kevent::new(), an EV_SET analogue Provide EV_SET Oct 5, 2017
@alexcrichton
Copy link
Member

Oh so actually you may want to look for invocations of the f! macro, we typically provide functions for C macros rather than literal Rust macros

@vojtechkral
Copy link
Contributor Author

Ok, take three using f!. I ended up figuring out defining a couple of helper type aliases is probably the best way. I also noticed kevent filter consts have a wrong type on netbsd.

pub type kevent_nevents = ::c_int;
pub type kevent_filter = ::int16_t;
pub type kevent_flags = ::uint16_t;
pub type kevent_fflags = ::uint32_t;
Copy link
Member

Choose a reason for hiding this comment

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

Hm if these don't actually exist, how come we're defining them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, the idea is that, for example, kevent_nevents is "the type that the kevent function uses for the nevents param on this BSD variant" (it varies). So that in user code I can cast a variable as kevent_nevents without having to worry about which particular BSD I'm currently on. Same for the other kevent_* types.

Copy link
Member

Choose a reason for hiding this comment

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

That makes sense, yes, but it's not what libc does. We don't add things that aren't in headers.

@@ -1969,6 +1973,18 @@ f! {
pub fn WIFSTOPPED(status: ::c_int) -> bool {
_WSTATUS(status) == _WSTOPPED && WSTOPSIG(status) != 0x13
}

pub fn EV_SET(ident: ::uintptr_t, filter: kevent_filter, flags: kevent_flags,
Copy link
Member

Choose a reason for hiding this comment

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

These macros aren't like their C counterparts where they take a kevent as the first argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, yes, I wrote it this way so that you don't need to first create an uninitialized kevent struct. But I don't have a strong opinion on this...

Copy link
Member

Choose a reason for hiding this comment

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

I think we should stick to the C macros as much as possible

@vojtechkral
Copy link
Contributor Author

I'll fix those long lines...

@vojtechkral
Copy link
Contributor Author

Ok, so, since platform abstractions aren't allowed, I guess I'll just make this into the netbsd const fixes.

The only other way of making EV_SET independent of the underlying integer type would be to make it generic with Into<someCommonInteger>, but that's not supported by the f! macro and I don't know whether it's allowed in terms of policy (I presume not). So, there's no real reason to include EV_SET since it wouldn't really do anything...

@alexcrichton
Copy link
Member

Ok, sounds like EV_SET should be left out?

@vojtechkral
Copy link
Contributor Author

Sorry for the delay. So I just reduced this to the fix for NetBSD. (Waiting for CI now.)

@vojtechkral vojtechkral changed the title Provide EV_SET Fix kqueue filter consts type on NetBSD [WAS: Provide EV_SET] Oct 23, 2017
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 24, 2017

📌 Commit a0e683e has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Oct 24, 2017

⌛ Testing commit a0e683e with merge 42b24bf...

bors added a commit that referenced this pull request Oct 24, 2017
Fix kqueue filter consts type on NetBSD [WAS: Provide EV_SET]

Using BSD kqueue's `kevent` structure is tedious, because some BSD variants define the structure slightly differently. This forces user's code to differentiate between BSD variants and initialize `kevent` accordingly, which is annoying and error-prone.

For an example, refer to [MIO](https://github.com/carllerche/mio/blob/master/src/sys/unix/kqueue.rs#L38).

This is an attempt to fix it - provide a ctor function with the same signature across BSD variants.

Is an `impl` piece for a C structure allowed in libc?

**edit:** I noticed the `kevent` function has a similar problem, maybe I should include a fix for that too...
**edit:** ^ Done
@bors
Copy link
Contributor

bors commented Oct 24, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 42b24bf to master...

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.

None yet

3 participants