feat: expose the inner fd of Kqueue

[SteveLauC]

What does this PR do

1. impl AsFd for Kqueue
2. impl From<Kqueue> for OwnedFd

The author of #2183 wants to use the inner fd to identify a Kqueue instance, this PR implements it, so closes #2183

Should we do impl AsRawFd for it as well, I don't have any strong view over this, but if we have made decision on this, we should do it to all the I/O-safe types

Checklist:

• I have read CONTRIBUTING.md
• I have written necessary tests and rustdoc comments
• A change log has been added if this PR modifies nix's API

[asomers]

I think this PR is probably ok. But I still don't understand @eesekaj's use case. It sounds like he wants to close the file descriptor without dropping the Kqueue, which is very unsafe.

[eesekaj]

I think this PR is probably ok. But I still don't understand @eesekaj's use case. It sounds like he wants to close the file descriptor without dropping the Kqueue, which is very unsafe.

Calling close() on a file descriptor will remove any kevents that reference the descriptor.

There is no way to drop Kqueue in kernel form userland. And I don't need the instance Kqueue which is created by nix crate, because we have our own abstraction above raw FD and FD is used to identify the instance. If I extract FD from Kqueue, in this case the Kqueu should be consumed and dropped automatically. But in previous implementation, it was made private and no way to even read the FD number.

[asomers]

I think this PR is probably ok. But I still don't understand @eesekaj's use case. It sounds like he wants to close the file descriptor without dropping the Kqueue, which is very unsafe.

Calling close() on a file descriptor will remove any kevents that reference the descriptor.

There is no way to drop Kqueue in kernel form userland.

Are you aware that dropping the Kqueue will automatically close its file descriptor?

And I don't need the instance Kqueue which is created by nix crate, because we have our own abstraction above raw FD and FD is used to identify the instance. If I extract FD from Kqueue, in this case the Kqueu should be consumed and dropped automatically. But in previous implementation, it was made private and no way to even read the FD number.

If you have your own abstraction anyway and don't use our Kqueue::kevent then yes I agree with what you said in the issue. You should just use libc directly because our abstraction isn't providing any benefit to you.

[SteveLauC]

Should we merge this?

[asomers]

I think your PR is reasonable. The only troubling part is @eesekaj 's explanation for why he wanted it. He never did fully explain it. I think he was trying to close the kqueue, and didn't understand that closing it happens automatically on drop.

[SteveLauC]

The only troubling part is @eesekaj 's explanation for why he wanted it. He never did fully explain it. I think he was trying to close the kqueue, and didn't understand that closing it happens automatically on drop.

Maybe that usage is very specific to their project, and they switched to the libc crate