于 2012-7-24 2:15, Blue Swirl 写道:
On Wed, Jul 18, 2012 at 8:51 AM, 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 ma
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 laye
On Wed, Jul 18, 2012 at 8:51 AM, 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
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 bloc
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, Ste
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.
>
>
> http://berrange.com/posts/
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 l
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
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 Block
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 wi
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 re
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'
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 *'
> concur
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 blo
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 th
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
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 othe
> 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 ot
On Wed, Jul 18, 2012 at 9:51 AM, Wenchao Xia 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, int nb_sectors);
Whe
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
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 most
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 yo
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
于 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;
于 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
ins
> 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' re
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
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 woul
On Fri, Jul 13, 2012 at 11:33 AM, Paolo Bonzini 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 GPL cod
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, Stef
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
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
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) shoul
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
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
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 metada
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 w
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 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 mak
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 i
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
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 JS
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.
>>
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 cli
于 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 t
于 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 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 def
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
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.
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
51 matches
Mail list logo
