From: Paolo Bonzini <pbonzini@redhat.com>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
"Stefan Hajnoczi" <stefanha@linux.vnet.ibm.com>,
"Michael Tokarev" <mjt@tls.msk.ru>, Lluís <xscript@gmx.net>,
qemu-devel@nongnu.org, "Blue Swirl" <blauwirbel@gmail.com>,
"Stefan Weil" <weil@mail.berlios.de>,
"Hannes Reinecke" <hare@suse.de>
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Wed, 18 Jul 2012 11:03:23 +0200 [thread overview]
Message-ID: <50067BDB.8000309@redhat.com> (raw)
In-Reply-To: <500678F7.1030705@linux.vnet.ibm.com>
Il 18/07/2012 10:51, Wenchao Xia ha scritto:
> 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.
block_int.h is BSD-licensed. It's compatible.
> 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.
I'll note that img_create, and almost all retrieval functions cannot be
implemented on top of NBD.
> /* structure init and uninit */
> BlockDriverState *qbdrvs_new(const char *device_name);
device_name is not needed in the library.
> void qbdrvs_delete(BlockDriverState *bs);
Being able to reuse the same BDS with close/open is one of the worst
parts of the QEMU block layer. It is only needed to implement eject in
QEMU. Let's get things right, and only have open/close:
int qbdrvs_open(BlockDriverState **bs, const char *filename, int flags,
const char *format_name);
void qbdrvs_close(BlockDriverState *bs);
>
>
> /* file open and close */
> int qbdrvs_open(BlockDriverState *bs, const char *filename, int flags,
> BlockDriver *drv);
You didn't have an API to find the BlockDriver *. Let's just pass a
format name, or NULL for probing (see above). This is consistent with
qbdrvs_img_create.
> 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);
>
>
> /* 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);
I would like to have also a scatter gather API (qbdrvs_readv and
qbdrvs_writev) taking a "struct iovec *iov, int niov" instead of
"uint8_t *buf, int nb_sectors".
flush is missing.
>
> /* info retrieve */
> //sector, size and geometry info
> int qbdrvs_get_info(BlockDriverState *bs, BlockDriverInfo *bdi);
One problem here is that BlockDriverInfo may grow in the future. This
is a problem for the ABI of the library. I don't have any particular
ideas here, except adding a separate API to the library for each member
of BlockDriverInfo.
> int64_t qbdrvs_getlength(BlockDriverState *bs);
qbdrvs_get_length.
> int64_t qbdrvs_get_allocated_file_size(BlockDriverState *bs);
> void qbdrvs_get_geometry(BlockDriverState *bs, uint64_t *nb_sectors_ptr);
Not needed, it's the same as bdrv_getlength.
> //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);
> void qbdrvs_get_full_backing_filename(BlockDriverState *bs,
> char *dest, size_t sz);
>
>
> /* advanced image content access */
> int qbdrvs_is_allocated(BlockDriverState *bs, int64_t sector_num, int
> nb_sectors,
> int *pnum);
> int qbdrvs_discard(BlockDriverState *bs, int64_t sector_num, int
> nb_sectors);
> int qbdrvs_has_zero_init(BlockDriverState *bs);
Paolo
next prev parent reply other threads:[~2012-07-18 9:03 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 8:54 [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API Wenchao Xia
2012-07-09 9:13 ` Paolo Bonzini
2012-07-10 5:04 ` Wenchao Xia
2012-07-10 7:17 ` Paolo Bonzini
2012-07-13 9:16 ` Stefan Hajnoczi
2012-07-13 9:51 ` Paolo Bonzini
2012-07-13 11:33 ` Paolo Bonzini
2012-07-13 15:03 ` Michael Tokarev
2012-07-13 15:17 ` Blue Swirl
2012-07-13 17:07 ` Stefan Weil
2012-07-13 22:55 ` Lluís Vilanova
2012-07-16 10:39 ` Stefan Hajnoczi
2012-07-23 11:55 ` Lluís Vilanova
2012-07-23 12:09 ` Paolo Bonzini
2012-07-24 9:33 ` Lluís Vilanova
2012-07-16 8:16 ` Wenchao Xia
2012-07-16 8:19 ` Paolo Bonzini
2012-07-18 8:51 ` Wenchao Xia
2012-07-18 9:03 ` Paolo Bonzini [this message]
2012-07-18 15:28 ` Kevin Wolf
2012-07-18 9:41 ` Stefan Hajnoczi
2012-07-18 10:42 ` Paolo Bonzini
2012-07-18 12:50 ` Stefan Hajnoczi
2012-07-18 13:51 ` Andreas Färber
2012-07-18 13:55 ` Kevin Wolf
2012-07-18 13:58 ` Daniel P. Berrange
2012-07-18 14:02 ` Paolo Bonzini
2012-07-18 14:12 ` Daniel P. Berrange
2012-07-18 15:23 ` Kevin Wolf
2012-07-18 15:35 ` Daniel P. Berrange
2012-07-19 11:37 ` Paolo Bonzini
2012-07-20 11:38 ` Daniel P. Berrange
2012-07-20 11:53 ` Paolo Bonzini
2012-07-23 18:15 ` Blue Swirl
2012-07-25 8:08 ` Wenchao Xia
2012-07-09 9:27 ` Daniel P. Berrange
2012-07-10 5:37 ` Wenchao Xia
2012-07-10 7:18 ` Paolo Bonzini
2012-07-13 9:12 ` Stefan Hajnoczi
2012-07-13 9:16 ` Daniel P. Berrange
2012-07-13 9:47 ` Stefan Hajnoczi
2012-07-16 7:48 ` Wenchao Xia
2012-07-09 14:36 ` Christoph Hellwig
2012-07-10 5:42 ` Wenchao Xia
2012-07-13 9:13 ` Stefan Hajnoczi
2012-07-13 9:27 ` Christoph Hellwig
2012-07-13 9:43 ` Stefan Hajnoczi
2012-07-13 10:42 ` Kevin Wolf
2012-07-13 10:55 ` Christoph Hellwig
2012-07-13 11:19 ` Kevin Wolf
2012-07-16 7:55 ` Wenchao Xia
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=50067BDB.8000309@redhat.com \
--to=pbonzini@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=hare@suse.de \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
--cc=weil@mail.berlios.de \
--cc=xiawenc@linux.vnet.ibm.com \
--cc=xscript@gmx.net \
/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).