于 2012-7-24 2:15, Blue Swirl 写道:
On Wed, Jul 18, 2012 at 8:51 AM, Wenchao Xia xiaw...@linux.vnet.ibm.com 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
Paolo Bonzini writes:
Il 23/07/2012 13:55, Lluís Vilanova ha scritto:
I have no problems relicensing to GPLv2 or later or GPLv3 or later.
What about LGPLv2+? (Note the L.)
I'd prefer to keep it non-lesser. Is it absolutely necessary?
This is about making the block layer part of a
Stefan Hajnoczi writes:
[...]
So I tried trimming down the list of files needed to compile
qemu tools, and here is a list:
Easy to relicense to LGPLv2+:
block/raw.c none (GPLv2+: Red Hat, IBM)
error.c LGPLv2 (Red Hat, IBM, Stefan Weil)
Il 23/07/2012 13:55, Lluís Vilanova ha scritto:
I have no problems relicensing to GPLv2 or later or GPLv3 or later.
What about LGPLv2+? (Note the L.)
I'd prefer to keep it non-lesser. Is it absolutely necessary?
This is about making the block layer part of a library. The block layer
is 90%
On Wed, Jul 18, 2012 at 8:51 AM, Wenchao Xia xiaw...@linux.vnet.ibm.com 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
On Thu, Jul 19, 2012 at 01:37:11PM +0200, Paolo Bonzini wrote:
Il 18/07/2012 17:35, Daniel P. Berrange ha scritto:
Oh, and will this library depend on glib
Yes, in all likelihood.
, and will it have the
abort-on-oom behaviour QEMU has ? From a libvirt POV, we won't
use any library
Il 20/07/2012 13:38, Daniel P. Berrange ha scritto:
There's two aspects to it. First we forbid use of malloc/free/realloc
in favour of an alternative set of APIs designed such that we can get
compile time errors when people don't check the result for NULL.
Il 18/07/2012 17:35, Daniel P. Berrange ha scritto:
Oh, and will this library depend on glib
Yes, in all likelihood.
, and will it have the
abort-on-oom behaviour QEMU has ? From a libvirt POV, we won't
use any library that aborts-on-oom.
Out of curiosity, how do you test OOM?
Paolo
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
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
On Wed, Jul 18, 2012 at 9:51 AM, Wenchao Xia xiaw...@linux.vnet.ibm.com wrote:
/* 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,
Whether to provide sync and/or async access is a key question.
Indeed.
Synchronous APIs are great for writing dedicated tools like dd, cp,
convert, etc.
Asynchronous APIs are essential for integrating image file I/O into
event-driven programs like libvirt. Here, the ability to do other
On Wed, Jul 18, 2012 at 06:42:24AM -0400, Paolo Bonzini wrote:
Synchronous APIs are great for writing dedicated tools like dd, cp,
convert, etc.
Asynchronous APIs are essential for integrating image file I/O into
event-driven programs like libvirt. Here, the ability to do other
Am 18.07.2012 10:51, schrieb Wenchao Xia:
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. [...]
So let the bikeshedding begin: ;)
What about qbds_ prefix
Am 18.07.2012 15:51, schrieb Andreas Färber:
Am 18.07.2012 10:51, schrieb Wenchao Xia:
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. [...]
After the
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
Il 18/07/2012 15:58, Daniel P. Berrange ha scritto:
How is error reporting dealt with
These APIs just return errno values.
, 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 *'
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
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
Am 18.07.2012 11:03, schrieb Paolo Bonzini:
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);
What is flags?
Are we really happy with a
On Wed, Jul 18, 2012 at 02:58:46PM +0100, Daniel P. Berrange wrote:
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
On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:37, Wenchao Xia ha scritto:
For getting the other metadata about the disk image you mention, another
possibility to is just make 'qemu-img info'
于 2012-7-13 17:27, Christoph Hellwig 写道:
On Fri, Jul 13, 2012 at 10:13:15AM +0100, Stefan Hajnoczi wrote:
How is that different from all the qemu-io commands?
qemu-io has no modes to just dumb the output without additional
information / statistics or for the write case just take user input
于 2012-7-13 19:33, Paolo Bonzini 写道:
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would use;
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
On Sat, Jul 14, 2012 at 01:55:07AM +0300, Lluís Vilanova wrote:
Paolo Bonzini writes:
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a)
On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:37, Wenchao Xia ha scritto:
For getting the other metadata about the disk image you mention, another
possibility to is just make 'qemu-img info' return the data in a machine
parseable format, ie JSON make a
On Mon, Jul 09, 2012 at 04:36:07PM +0200, Christoph Hellwig wrote:
On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote:
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
On Tue, Jul 10, 2012 at 09:17:05AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:04, Wenchao Xia ha scritto:
于 2012-7-9 17:13, Paolo Bonzini 写道:
Il 09/07/2012 10:54, Wenchao Xia ha scritto:
Following is my implementing plan draft:
1 introduce libqblock.so in sub directory in qemu.
On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:37, Wenchao Xia ha scritto:
For getting the other metadata about the disk image you mention, another
possibility to is just make 'qemu-img
On Fri, Jul 13, 2012 at 10:13:15AM +0100, Stefan Hajnoczi wrote:
How is that different from all the qemu-io commands?
qemu-io has no modes to just dumb the output without additional
information / statistics or for the write case just take user input
instead of a pattern. I actually tried to add
On Fri, Jul 13, 2012 at 11:27:55AM +0200, Christoph Hellwig wrote:
On Fri, Jul 13, 2012 at 10:13:15AM +0100, Stefan Hajnoczi wrote:
How is that different from all the qemu-io commands?
qemu-io has no modes to just dumb the output without additional
information / statistics or for the write
On Fri, Jul 13, 2012 at 10:16:40AM +0100, Daniel P. Berrange wrote:
On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:37, Wenchao Xia ha scritto:
For getting the other metadata about the
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would use; b) told us why the library should not be under
the GPL.
Please design first
Am 13.07.2012 11:43, schrieb Stefan Hajnoczi:
On Fri, Jul 13, 2012 at 11:27:55AM +0200, Christoph Hellwig wrote:
On Fri, Jul 13, 2012 at 10:13:15AM +0100, Stefan Hajnoczi wrote:
How is that different from all the qemu-io commands?
qemu-io has no modes to just dumb the output without
On Fri, Jul 13, 2012 at 12:42:41PM +0200, Kevin Wolf wrote:
It still feels a bit more like qemu-io-style operations. Not sure what
your use case looks like exactly, but adding a qemu-io command that
reads data from a file and writes it at a given offset into the images
(or vice versa) should
Am 13.07.2012 12:55, schrieb Christoph Hellwig:
On Fri, Jul 13, 2012 at 12:42:41PM +0200, Kevin Wolf wrote:
It still feels a bit more like qemu-io-style operations. Not sure what
your use case looks like exactly, but adding a qemu-io command that
reads data from a file and writes it at a given
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would use; b) told us why the library should not
On 13.07.2012 15:33, Paolo Bonzini wrote:
[]
So I tried trimming down the list of files needed to compile
qemu tools, and here is a list:
Easy to relicense to LGPLv2+:
block/raw.c none (GPLv2+: Red Hat, IBM)
error.c LGPLv2 (Red Hat, IBM, Stefan
On Fri, Jul 13, 2012 at 11:33 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the
Am 13.07.2012 13:33, schrieb Paolo Bonzini:
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would
Paolo Bonzini writes:
Il 13/07/2012 11:51, Paolo Bonzini ha scritto:
Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto:
Working around the QEMU block layer license is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would use; b) told us why
Il 10/07/2012 07:04, Wenchao Xia ha scritto:
于 2012-7-9 17:13, Paolo Bonzini 写道:
Il 09/07/2012 10:54, Wenchao Xia ha scritto:
Following is my implementing plan draft:
1 introduce libqblock.so in sub directory in qemu.
2 write a nbd client in libqblock, similar to qemu nbd client. Then
Il 10/07/2012 07:37, Wenchao Xia ha scritto:
For getting the other metadata about the disk image you mention, another
possibility to is just make 'qemu-img info' return the data in a machine
parseable format, ie JSON make a client API for extracting data from
this JSON document.
Thank u
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
as management stack or block tools, to access images data directly.
Following is the objects:
(1) API to write/read block device at
Il 09/07/2012 10:54, Wenchao Xia ha scritto:
Following is my implementing plan draft:
1 introduce libqblock.so in sub directory in qemu.
2 write a nbd client in libqblock, similar to qemu nbd client. Then
use it to talk with nbd server, by default is qemu-nbd, to get access
to images. In
On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote:
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
as management stack or block tools, to access images data directly.
On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote:
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
as management stack or block tools, to access images data directly.
于 2012-7-9 17:13, Paolo Bonzini 写道:
Il 09/07/2012 10:54, Wenchao Xia ha scritto:
Following is my implementing plan draft:
1 introduce libqblock.so in sub directory in qemu.
2 write a nbd client in libqblock, similar to qemu nbd client. Then
use it to talk with nbd server, by default is
于 2012-7-9 17:27, Daniel P. Berrange 写道:
On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote:
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
as management stack or block
于 2012-7-9 22:36, Christoph Hellwig 写道:
On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote:
Hi, Paolo and folks,
qemu have good capabilities to access different virtual disks, I want
to expose its block layer API to let 3rd party program linked in, such
as management stack or block
51 matches
Mail list logo
