From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrW7O-0000yK-PP for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:24:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrW7G-0005UZ-8B for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:24:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrW7F-0005TZ-V4 for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:24:42 -0400 Message-ID: <5006D4FE.8020204@redhat.com> Date: Wed, 18 Jul 2012 17:23:42 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4FFBB7FB.3070303@linux.vnet.ibm.com> <4FFBD6F1.90403@redhat.com> <20120713091611.GC15503@stefanha-thinkpad.localdomain> <4FFFEF8E.5080705@redhat.com> <50000793.2020401@redhat.com> <5003CDC6.2040103@linux.vnet.ibm.com> <5003CE8B.20804@redhat.com> <500678F7.1030705@linux.vnet.ibm.com> <20120718135846.GE2294@redhat.com> <5006C1E7.2070407@redhat.com> <20120718141230.GG2294@redhat.com> In-Reply-To: <20120718141230.GG2294@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , Stefan Hajnoczi , Michael Tokarev , =?UTF-8?B?TGx1w61z?= , qemu-devel@nongnu.org, Blue Swirl , Stefan Weil , Hannes Reinecke , Paolo Bonzini , Wenchao Xia Am 18.07.2012 16:12, schrieb Daniel P. Berrange: > On Wed, Jul 18, 2012 at 04:02:15PM +0200, Paolo Bonzini wrote: >> Il 18/07/2012 15:58, Daniel P. Berrange ha scritto: >>> How is error reporting dealt with >> >> These APIs just return errno values. > > Which has led to somewhat unhelpful error reporting in the past. If we're > designing a library API it'd be nice to improve on this. But in most cases, errno is what we get from the OS, so we can't do much more than passing it on. Maybe we can do a bit better with bdrv_open(), which is relatively likely to fail in qemu rather than in the kernel because something's wrong with the content of the image. >>> , and what is the intent around >>> thread safety of the APIs ? I'd like to see a fully thread safe >>> API - multiple threads can use the same 'BlockDriverState *' >>> concurrently, and thread-local error reporting. >> >> This is a bit difficult to provide, since the QEMU block layer itself is >> not thread-safe. > > Yep, I'd expect that this is something we'd need to fix when turning the > code into a library. NB, I don't mean to say QEMU should protect against > an app doing stupid things like letting 2 threads write to the same area > of the file at once. That's upto the application. I simply mean that the > BlockDriverState shouldn't corrupt itself if 2 separate APIs are called > concurrently on the same instance. I think it makes sense to make the library thread-safe - and if it only means taking the global mutex like we do in qemu. I think threading is a good interface to allow clients to do AIO (even though possibly not the only one we want to provide), and eventually it will match what qemu is doing internally. Kevin