Hi,
On Tue, 15 Apr 2025 at 15:51, Daniel P. Berrangé <berra...@redhat.com> wrote:
> It is actually NOT really connected to lseek, and as such
* For file and fd channels _FEATURE_SEEKABLE is set when/if lseek(2) works.
->
https://gitlab.com/qemu-project/qemu/-/commit/401e311ff72e0a62c834bfe466de68a82cfd90cb
> QIO_CHANNEL_FEATURE_SEEKABLE is probably a bad choice of name
> in retrospect.
* That's plausible. Because while reading code, _SEEKABLE indicates
(or hints) that the underlying stream allows random access at a given
offset. Even pread(2)/pwrite(2) manuals say that -> file referenced by
fd should be capable of seeking. So correlation is that, since
QIO_CHANNEL is an abstraction layer, it supports different
streams/channels underneath, maybe some of those underneath streams
support seeking (random access) and some don't. Hence we set
_FEATURE_SEEKABLE when the underlying channel/stream supports it.
> In QIOChanel API specification, having QIO_CHANNEL_FEATURE_SEEKABLE
> set is a pre-requisite for use of qio_channel_{pread,preadv,pwrite,pwritev}.
* If *_FEATURE_SEEKABLE is not connected to lseek(2) or seeking, what
is its right interpretation? Why is it a pre-requisite for use of
qio_channel_{pread,preadv,pwrite,pwritev} functions?
Thank you.
---
- Prasad
