* I have a question around the semantics of `embedded_io::Read::read` and thefore - also for `std::io::Read::read` and also for `embedded_io_async::read::Read`:

1. Say (for simplicity) these operate off from some internal buffer. Could be - for example - the ringbuffer of the TCP stack
2. Assuming the user had passed a buffer of size N:

- Is `read` _guaranteed_ to return without blocking, if there is at least one byte in the internal TCP ringbuffer?
- If there are NO bytes in the internal TCP ringbuffer, is `read` _guaranteed_  to return immediately after _at least one byte_ pops into the TCP ringbuffer (there could be more, but the point is, _read_ is guaranteed NOT to wait for N bytes) and will return as soon as _some_ bytes are available from the internal ringbuffer

I'm basically trying to understand whether the semantics of `read` is:

- Option A: return as soon as there is at least one byte in the internal OS buffer, or wait, but only until at least one byte appears in the OS buffer, but once this byte (could be more!) appear, return these bytes **without waiting for all the N bytes of the user buffer**
- Option B: the implementation is free to block for as long as it wants, and in particular -  **blocking (indefinitely) until it can return all N bytes**. With this option, it is up to the user to supply a smaller buffer (in the corner case - a buffer of just one byte, if the user is unsure how many bytes might arrive - ever)

The background is that I'm confronted with a `read` implementation that does "Option B", and I wonder whether it actually does fullfil the `embedded_io::Read` contract. dirbaio sorry for pinging, but since `embedded_io` was your initiative originally, perhaps you know this?