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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.