All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.