On Friday, April 04, 2025 12:14 CEST, Prasad Pandit <ppan...@redhat.com> wrote:
> * If the r/w pointer adjustment (lseek(2)) is not required, then why > set the '*_FEATURE_SEEKABLE' flag? The QIO_CHANNEL_FEATURE_SEEKABLE flag is set to indicate that the channel supports seekable operations. This flag is more about signaling capability rather than dictating the use of the specific lseek(2) function. > * The qio_channel_block_preadv/pwritev functions defined above, which > shall be called via '->io_preadv' and '->io_pwritev' methods, appear > to call bdrv_readv/writev_vmstate() functions. Do those functions need > to adjust (lseek(2)) the stream r/w pointers? In this case, I don't think any lseek(2) is involved, instead some flavor of pread(2) is used, which, according to the man page, requires that > The file referenced by fd must be capable of seeking. because pread(2) internally manages seeking without modifying the file descriptor's offset. Let me split the question here: * Do those functions need to seek into the channel? Yes * Do those functions lseek(2) the stream r/w pointers? No, they do not use lseek(2). The seeking is managed internally by the pread(2) and co. functions, which perform I/O operations at specified offsets without altering the file descriptor's position. I hope this clarifies :) Best, Marco
