From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Prasad Pandit <ppandit@redhat.com>
Cc: Marco Cavenati <Marco.Cavenati@eurecom.fr>,
Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] migration: add FEATURE_SEEKABLE to QIOChannelBlock
Date: Tue, 15 Apr 2025 12:03:17 +0100 [thread overview]
Message-ID: <Z_489fbXq-1Ihnhu@redhat.com> (raw)
In-Reply-To: <CAE8KmOz-yGRXo2RiPpnhtcg2K+j38sK6C1eGHvpQf0L_Hfe3vw@mail.gmail.com>
On Tue, Apr 15, 2025 at 04:14:08PM +0530, Prasad Pandit wrote:
> Hi,
>
> On Tue, 15 Apr 2025 at 15:51, Daniel P. Berrangé <berrange@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
Yes I know, checking lseek is a proxy that determines whether
preadv will work or not. This is basically validating that
the file/fd is not a FIFO/pipe/character device. It must be
a block device or regular file.
> > 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?
Because that's what the QEMU API specification declares
* Not all implementations will support this facility, so may report
* an error. To avoid errors, the caller may check for the feature
* flag QIO_CHANNEL_FEATURE_SEEKABLE prior to calling this method.
and what the QEMU API impl defines
ssize_t qio_channel_pwritev(QIOChannel *ioc, const struct iovec *iov,
size_t niov, off_t offset, Error **errp)
{
QIOChannelClass *klass = QIO_CHANNEL_GET_CLASS(ioc);
if (!klass->io_pwritev) {
error_setg(errp, "Channel does not support pwritev");
return -1;
}
if (!qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_SEEKABLE)) {
error_setg_errno(errp, EINVAL, "Requested channel is not seekable");
return -1;
}
return klass->io_pwritev(ioc, iov, niov, offset, errp);
}
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-04-15 11:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 14:14 [PATCH] migration: add FEATURE_SEEKABLE to QIOChannelBlock Marco Cavenati
2025-04-04 8:19 ` Prasad Pandit
2025-04-04 9:04 ` Marco Cavenati
2025-04-04 10:14 ` Prasad Pandit
2025-04-04 12:05 ` Marco Cavenati
2025-04-07 6:47 ` Prasad Pandit
2025-04-07 9:00 ` Marco Cavenati
2025-04-08 5:25 ` Prasad Pandit
2025-04-08 15:03 ` Marco Cavenati
2025-04-15 10:21 ` Daniel P. Berrangé
2025-04-15 10:44 ` Prasad Pandit
2025-04-15 11:03 ` Daniel P. Berrangé [this message]
2025-04-15 11:57 ` Prasad Pandit
2025-04-15 12:03 ` Daniel P. Berrangé
2025-04-10 19:52 ` Fabiano Rosas
2025-04-11 8:48 ` Marco Cavenati
2025-04-11 12:24 ` Fabiano Rosas
2025-04-15 10:15 ` Marco Cavenati
2025-04-15 13:50 ` Fabiano Rosas
2025-04-17 9:10 ` Marco Cavenati
2025-04-17 15:12 ` Fabiano Rosas
2025-04-24 13:44 ` Marco Cavenati
2025-05-08 20:23 ` Peter Xu
2025-05-09 12:51 ` Marco Cavenati
2025-05-09 16:21 ` Peter Xu
2025-05-09 21:14 ` Marco Cavenati
2025-05-09 22:04 ` Peter Xu
2025-09-16 16:06 ` Marco Cavenati
2025-09-19 21:24 ` Fabiano Rosas
2025-09-22 15:51 ` Marco Cavenati
2025-09-30 20:12 ` Fabiano Rosas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z_489fbXq-1Ihnhu@redhat.com \
--to=berrange@redhat.com \
--cc=Marco.Cavenati@eurecom.fr \
--cc=farosas@suse.de \
--cc=peterx@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).