qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs
Date: Sun, 15 Mar 2009 15:48:43 +0100	[thread overview]
Message-ID: <20090315144843.GC30986@lst.de> (raw)
In-Reply-To: <49BCF79D.8050103@redhat.com>

On Sun, Mar 15, 2009 at 02:42:05PM +0200, Avi Kivity wrote:
> Christoph Hellwig wrote:
> >QEMUIOVector is a useful helper for the dma-helper.c internals but for a 
> >generic
> >block API it's more of hindrance.  Some top-level consumers like virtio-blk
> >already have the plain iovec and segment number at hand and can pass it 
> >down
> >directly, and for those that just have a single element and need to fake up
> >a vector the plain iovec also is a lot easier.
> >  
> 
> virtio gets its iovecs through a hacky (and incorrect, try >=4G) 
> method.  IMO virtio should be fixed to use the dma api, at which point 
> it will start to use QEMUIOVector anyway,

I would not call it hacky an incorrect.  And the current dma API
certainly won't work due to the layering between the generic virtio
layer and virtio-block.

> Internally yes, but why should bdrv_* not use QEMUIOVector?  That API 
> isn't very interested in posix.

Because it makes life a lot easier.  We already pass the length in
sector units anyway.  While QEMUIOVector could replace instead of
currently duplicate it that would mean another translation between
byte and sector units at the block level.  And then comes the issue
of feeding in iovecs - there is the case of iovecs coming from other
layers like virtio-blk and the more important one of just creating
one-entry static iovecs in many places.  These would mean another
dynamic allocation and lots of API churn.

Keep the QEMUIOVector as a nice abstraction for the memory-managment
issues in dma-helper.c but I think as an API for passing data (which
doesn't care about how the iovec array is allocated) they aren't
very helpful.

> 
> > static BlockDriverAIOCB *bdrv_aio_rw_vector(BlockDriverState *bs,
> >                                             int64_t sector_num,
> >-                                            QEMUIOVector *iov,
> >+                                            struct iovec *iov,
> >+					    int nr_iov,
> >                                             int nb_sectors,
> >                                             BlockDriverCompletionFunc *cb,
> >                                             void *opaque,
> >  
> 
> Note qemu never uses tabs in source code.

Sorry, tried to get rid of most of them, but it's a real pain in the
ass writing code that way ;-)  Guess I need to write me a little
obsfucate.awk script before submitting patches..

  parent reply	other threads:[~2009-03-15 14:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-14 19:27 [Qemu-devel] [PATCH 0/6] add real vectored block I/O support Christoph Hellwig
2009-03-14 19:27 ` [Qemu-devel] [PATCH 1/6] more BlockDriver C99 initializers Christoph Hellwig
2009-03-28 18:35   ` Christoph Hellwig
2009-03-14 19:28 ` [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs Christoph Hellwig
2009-03-15 12:42   ` Avi Kivity
2009-03-15 13:20     ` Anthony Liguori
2009-03-15 13:36       ` Avi Kivity
2009-03-15 14:48     ` Christoph Hellwig [this message]
2009-03-15 15:07       ` Avi Kivity
2009-03-15 16:35         ` Christoph Hellwig
2009-03-14 19:28 ` [Qemu-devel] [PATCH 3/6] virtio-blk: use generic vectored I/O APIs Christoph Hellwig
2009-03-14 19:30 ` [Qemu-devel] [PATCH 4/6] remove bdrv_aio_read/bdrv_aio_write Christoph Hellwig
2009-03-14 19:30 ` [Qemu-devel] [PATCH 5/6] push down vector linearization to posix-aio-compat.c Christoph Hellwig
2009-03-14 19:31 ` [Qemu-devel] [PATCH 6/6] experimental native preadv/pwritev support for Linux Christoph Hellwig
2009-03-15 14:36   ` Blue Swirl
2009-03-15 14:44     ` Christoph Hellwig
2009-03-15 15:03       ` Blue Swirl
2009-03-15 15:16         ` Christoph Hellwig
2009-03-16 11:38   ` Gerd Hoffmann
2009-03-16 11:53     ` Christoph Hellwig

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=20090315144843.GC30986@lst.de \
    --to=hch@lst.de \
    --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).