qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 :|



  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).