qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI
Date: Sat, 17 Sep 2011 08:11:10 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Sep 16, 2011 at 05:53:20PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 14, 2011 at 04:50:25PM +0100, Stefan Hajnoczi wrote:
> > I think in this case it will not make the code nicer.  Since the
> > external iSCSI library is based on callbacks it would be necessary to
> > write the coroutines<->callbacks adapter functions.  So for example,
> > the READ10 command would need a function that can be called in
> > coroutine context and yields while libiscsi does the I/O.  When the
> > callback is invoked it will re-enter the coroutine.
> > 
> > The area where coroutines are useful in the block layer is for image
> > formats.  We already have common coroutines<->callback adapter
> > functions in block.c so it's possible to write sequential code for
> > image formats.  They only need access to block layer functions which
> > have already been adapted.  But as soon as you interact with a
> > callback-based API from the coroutine, then you need to write an
> > adapter yourself.
> 
> So you plan on keeping the aio interface around forever?  Qemu with two
> different I/O pathes was already more than painful enough, I don't
> think keeping three, and two of them beeing fairly complex is a good
> idea.

The synchronous interfaces can be converted to the coroutine
interfaces.

The block layer needs a public aio interface because device emulation is
asynchronous/callback-based.  That doesn't mean that BlockDriver needs
aio functions since block.c could transparently set up coroutines.  So
in theory BlockDriver could have only coroutine interfaces.

Doing the aio to coroutine conversion is pretty mechanical, that's why
I'm not afraid of doing it with this iSCSI code later.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]