Remove lio_listio(2) support for DragonFly - Fix compile#805
Conversation
On FreeBSD and DragonflyBSD, kevent(2) has a distinct filter type for use with lio_listio(2). This commit adds 2 new public methods: UnixReady::lio and UnixReady::is_lio. This patch also deprecates AIO fns on platforms that do not support AIO.
|
Is there a way to get DragonFly added to the CI run? |
|
Not easiliy. Neither rustup nor japaric/cross support Dragonfly. I suppose that means that for Dragonfly, the toolchain is build from ports? Adding Dragonfly to CI would require creating a buildbot/jenkins instance, and it may not be possible to always use the same version of Rust for Dragonfly as for Travis. |
|
Yes, rust on DragonFly is build from ports (we call them "dports"). There is a docker script in the rust repo which cross-compiles Rust for DragonFly on Linux, but due to missing compute resources it never got enabled. So there are no "official" builds for DragonFly (yet). |
|
@carllerche: can we merge this, despite having no CI for DragonFly? |
|
Could you remove Dragonfly from the list of supported platforms? Unfortunately, I can't really claim it is supported unless there is CI. I can merge the PR otherwise. |
There is no EVFILT_LIO on DragonFly. Commit 00d8573 failed to compile on DragonFly. There seems to be no (official) LIO support, at least it is not mentioned anywhere in manpages etc. With this commit, mio can be build again on DragonFly and all tests pass.
|
@carllerche removed DragonFly from the list and "merged" the two commits into one. |
There is no EVFILT_LIO on DragonFly. Commit 00d8573 failed to
compile on DragonFly. There seems to be no (official) LIO support,
at least it is not mentioned anywhere in manpages etc.
With this commit, mio can be build again on DragonFly and all tests pass.