The two config functions (in version 6.0.2) have identical bodies but inconsistent, over-constrained bounds:
config_ktls_server: IO: AsRawFd + AsyncRead + AsyncReadReady + AsyncWrite + Unpin
config_ktls_client: IO: AsRawFd + AsyncRead + AsyncWrite + Unpin
Neither body uses AsyncWrite or AsyncReadReady. The only IO-touching operations are:
drain(&mut stream) — needs AsyncRead + Unpinsetup_inner(io.as_raw_fd(), ...) — needs AsRawFdKtlsStream::new(io, drained) — needs AsRawFd
AsyncReadReady is never invoked inside either function (the only call site is CorkStream::poll_read_ready).
Proposal: converge both to the minimal set the bodies require:
where IO: AsRawFd + AsyncRead + Unpin,
This is a backward-compatible loosening.
In my use case, I have a wrapping IO type that impls AsRawFd + AsyncRead + Unpin but not AsyncReadReady can be passed to config_ktls_client today but is rejected by config_ktls_server purely on the redundant bound.
If AsyncReadReady was meant to guarantee the returned KtlsStream<IO> is usable as AsyncRead, that bound already lives on impl AsyncRead for KtlsStream<IO>. Maybe there is no need to duplicate it on the config function, and not on the client/server asymmetrically.
The two config functions (in version 6.0.2) have identical bodies but inconsistent, over-constrained bounds:
Neither body uses
AsyncWriteorAsyncReadReady. The onlyIO-touching operations are:drain(&mut stream)— needsAsyncRead + Unpinsetup_inner(io.as_raw_fd(), ...)— needsAsRawFdKtlsStream::new(io, drained)— needsAsRawFdAsyncReadReadyis never invoked inside either function (the only call site isCorkStream::poll_read_ready).Proposal: converge both to the minimal set the bodies require:
This is a backward-compatible loosening.
In my use case, I have a wrapping
IOtype that implsAsRawFd + AsyncRead + Unpinbut notAsyncReadReadycan be passed toconfig_ktls_clienttoday but is rejected byconfig_ktls_serverpurely on the redundant bound.If
AsyncReadReadywas meant to guarantee the returnedKtlsStream<IO>is usable asAsyncRead, that bound already lives onimpl AsyncRead for KtlsStream<IO>. Maybe there is no need to duplicate it on the config function, and not on the client/server asymmetrically.