Tokio support

[meh]

Tokio support

[meh]

That's currently provided through mio, each Device implements mio::Evented which allows it to be used from tokio without doing anything tokio only.

What would be the difference with implementing tokio::Sink and tokio::Stream directly?

[vorner]

I might be missing something, but last time I looked at how Evented is used in tokio with PollEvented, it required quite a large amount of boilerplate code. So, the difference would be putting this boilerplate code into the crate itself so it can be reused, possibly behind a feature gate.

As a slightly related side note, when I discussed my code on the tokio gitter, I was told the Read and Write (and, in context of tokio, AsyncRead and AsyncWrite) traits aren't the best ones, because they assume the underlying object is stream of bytes, not bunch of discrete messages ‒ things like Write::write_all or Read::bytes make no sense in context of a TUN device that returns packets.

In that sense, having a Stream of packets seems like more natural API for that than AsyncRead provided by PollEvented. But having a recv method which returns a future, or a framed method, that takes a Codec and produces a stream of some messages, would make sense too.

[meh]

That's a good point, I'd be fine with a feature-gated tokio implementation alongside the mio one.