qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.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 16:51:03 +0800	[thread overview]
Message-ID: <500678F7.1030705@linux.vnet.ibm.com> (raw)
In-Reply-To: <5003CE8B.20804@redhat.com>

   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.


/* 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);


/* 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);
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);
//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);

> Il 16/07/2012 10:16, Wenchao Xia ha scritto:
>>>
>>    Really thanks for the investigation, I paid quite sometime to dig out
>> which license is compatible to LGPL, this have sorted it out.
>>    The coroutine and structure inside is quite a challenge.
>
> Coroutines are really just a small complication in the program flow if
> all you support is synchronous access to files (i.e. no HTTP etc.).
> Their usage should be completely transparent.
>
>> What about
>> provide the library first in nbd + sync access, and waiting for the
>> library employer response? If it is good to use, then replace implement
>> code to native qemu block layer code, change code's license, while keep
>> API unchanged.
>
> You can start by proposing the API.
>
> Paolo
>


-- 
Best Regards

Wenchao Xia

  reply	other threads:[~2012-07-18  8:51 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 [this message]
2012-07-18  9:03                   ` Paolo Bonzini
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=500678F7.1030705@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=blauwirbel@gmail.com \
    --cc=hare@suse.de \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    --cc=weil@mail.berlios.de \
    --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).