Hi,
On Fri, 4 Apr 2025 at 17:35, Marco Cavenati <marco.caven...@eurecom.fr> wrote:
> 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.
* Yes.
> 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.
* I think "...capable of seeking" is referring to lseek(2) here,
because the man page mentions:
===
...
ERRORS
pread() can fail and set errno to any error specified for read(2) or
lseek(2). pwrite() can fail and set errno to any error specified for
write(2) or lseek(2).
====
ie. pread/pwrite internally makes lseek(2) call.
> 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.
* If seeking is managed internally by pread(2)/pwrite(2) and co.
functions, then that is independent of the
'QIO_CHANNEL_FEATURE_SEEKABLE' flag; This flag is QEMU specific, it is
not available outside of QEMU/io/ system. pread(2)/pwrite(2) are
standard C library functions.
* Another question is: will pread(2)/pwrite(2) functions work the same
if we don't set the 'QIO_CHANNEL_FEATURE_SEEKABLE' flag?
(what I'm trying to say is: it is not clear how setting
'*_FEATURE_SEEKABLE' flag helps in case of QIOChannelBlock class)
Thank you.
---
- Prasad
