Skip to content

netlink-sys - updating async-io #17

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

Closed
plugwash opened this issue Feb 2, 2024 · 1 comment · Fixed by #25
Closed

netlink-sys - updating async-io #17

plugwash opened this issue Feb 2, 2024 · 1 comment · Fixed by #25

Comments

@plugwash
Copy link

plugwash commented Feb 2, 2024

Hi.

I am one of the Debian rust team and have been investigating updating our rust-async-io package from 1.x to 2.x. While we do have a mechanism for packaging multiple versions of a crate it's something we try to avoid where possible. So I looked into updating netlink-sys to use the new version of async-io.

The main change in the new version of async-io is the adoption of "IO safety". The idea that file descriptors should have their lifetimes managed in a similar manner to memory. This has meant a switch from RawFd/AsRawFd to BorrowedFd/AsFd. It also means that a number of functions have been marked as unsafe that were not previously so marked.

As I understand it this does not mean that the functions are any more dangerous than they were before, just that the danger must now be acknowledged.

I prepared an initial patch to make netlink-sys build with the new version of async-io, it can be found at https://salsa.debian.org/rust-team/debcargo-conf/-/blob/072d11ba3339504af28f15145681c48ad3894392/src/netlink-sys/debian/patches/async-io-2.patch

@cathay4t
Copy link
Member

cathay4t commented Feb 2, 2024

It will confuse other developer when they see unsafe without above comments.

I am sure when smol bump their API major version, they should provide safe migration suggestions, we should do that instead of adding unsafe keywords.

Revisit smol is on my TODO list for a while, I plan to do that in March 2024, if you have time to do that, PR is always welcome.

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 a pull request may close this issue.

2 participants