From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrUmY-0000LK-Jj for qemu-devel@nongnu.org; Wed, 18 Jul 2012 09:59:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrUmX-0002s1-2j for qemu-devel@nongnu.org; Wed, 18 Jul 2012 09:59:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrUmW-0002rw-Qu for qemu-devel@nongnu.org; Wed, 18 Jul 2012 09:59:13 -0400 Date: Wed, 18 Jul 2012 14:58:46 +0100 From: "Daniel P. Berrange" Message-ID: <20120718135846.GE2294@redhat.com> References: <4FFA9C30.2070201@linux.vnet.ibm.com> <4FFAA0C3.3080703@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <500678F7.1030705@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Anthony Liguori , Stefan Hajnoczi , Michael Tokarev , qemu-devel@nongnu.org, =?utf-8?B?TGx1w61z?= , Blue Swirl , Stefan Weil , Hannes Reinecke , Paolo Bonzini On Wed, Jul 18, 2012 at 04:51:03PM +0800, Wenchao Xia wrote: > Hi, following is API draft, prototypes were taken from qemu/block.h, > and the API prefix is changed frpm bdrv to qbdrvs, to declare related > object is BlockDriverState, not BlockDriver. One issue here is it may > require include block_int.h, which is not LGPL2 licensed yet. > API format is kept mostly the same with qemu generic block layer, to > make it easier for implement, and easier to make qemu migrate on it if > possible. How is error reporting dealt with, 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. > > > /* structure init and uninit */ > BlockDriverState *qbdrvs_new(const char *device_name); > void qbdrvs_delete(BlockDriverState *bs); > > > /* file open and close */ > int qbdrvs_open(BlockDriverState *bs, const char *filename, int flags, > BlockDriver *drv); > void qbdrvs_close(BlockDriverState *bs); > int qbdrvs_img_create(const char *filename, const char *fmt, > const char *base_filename, const char *base_fmt, > char *options, uint64_t img_size, int flags); s/img_create/create/ Can this return an actual BlockDriverState struct too. > > > /* sync access */ > int qbdrvs_read(BlockDriverState *bs, int64_t sector_num, > uint8_t *buf, int nb_sectors); > int qbdrvs_write(BlockDriverState *bs, int64_t sector_num, > const uint8_t *buf, int nb_sectors); > > > /* info retrieve */ > //sector, size and geometry info > int qbdrvs_get_info(BlockDriverState *bs, BlockDriverInfo *bdi); What is in BlockDriverInfo and what is the intended ABI stability policy for it ? > int64_t qbdrvs_getlength(BlockDriverState *bs); > int64_t qbdrvs_get_allocated_file_size(BlockDriverState *bs); > void qbdrvs_get_geometry(BlockDriverState *bs, uint64_t *nb_sectors_ptr); Could this data all just be part of BlockDriverInfo data ? > //image type > const char *qbdrvs_get_format_name(BlockDriverState *bs); > //backing file info > void qbdrvs_get_backing_filename(BlockDriverState *bs, > char *filename, int filename_size); You need to include the backing file format here too. > void qbdrvs_get_full_backing_filename(BlockDriverState *bs, > char *dest, size_t sz); Not sure I see why we need this in addition to the above ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|