qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/7] introduce BSD-licensed block driver for "ra


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH 0/7] introduce BSD-licensed block driver for "raw"
Date: Wed, 21 Aug 2013 10:20:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8

On 08/20/13 10:21, Kevin Wolf wrote:
> Am 16.08.2013 um 16:15 hat Laszlo Ersek geschrieben:
>> Paolo asked me to write such a driver based on his textual specification
>> alone. The first patch captures his email in full, the rest re-quotes
>> parts that are being implemented.
>>
>> The tree compiles at each patch. The series passes "make check-block".
>>
>> "block/raw.c" is not removed because I wanted to keep it out of my
>> series and out of my brain.
>>
>> Disclaimer: I couldn't care less if the raw block driver was public
>> domain or AGPLv3+, as long as it qualifies as free software. I'm only
>> trying to do what Paolo asked of me.
>>
>> Laszlo Ersek (7):
>>   add skeleton for BSD licensed "raw" BlockDriver
>>   raw_bsd: emit debug events in bdrv_co_readv() and bdrv_co_writev()
>>   raw_bsd: add raw_create()
>>   raw_bsd: introduce "special members"
>>   raw_bsd: add raw_create_options
>>   raw_bsd: register bdrv_raw
>>   switch raw block driver from "raw.o" to "raw_bsd.o"
>>
>>  block/Makefile.objs |    2 +-
>>  block/raw_bsd.c     |  186 
>> +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 187 insertions(+), 1 deletions(-)
>>  create mode 100644 block/raw_bsd.c
> 
> Reviewed if the individual added functions make sense, whether all
> necessary function from struct BlockDriver are implemented, and which
> fields from BlockDriverState need special handling (it's only bs->sg,
> and we should probably get rid of that requirement)
> 
> Looks good in general, but please CC Stefan and me for v2 (like for all
> block patches).

Thanks for the review.

Regarding your comments for 4/7: can we postpone the bdrv_is_sg() change
to another series?

Because, I can't just rebase / update this series as a "normal" series
-- v2 will still be a "clean room reimplementation", and I must keep
full history (basically, a documentation of the "clean room process") in
the commit log.

So, Paolo's suggestion for 7/7 (ie. raw_reopen_prepare() should just
return 0) will be a separate 8/8, with his email quoted as commit
message. (Normally I would just squash the change and add a short v2
note *outside* the commit log, but that's exactly what we can't do here.)

... Maybe I can still squash the change into 7/7, and extend only the
commit message with Paolo's email, since that includes the wrong v1 code
too.

Anyway, under this MO, I have trouble implementing what you want, if
only from the "how to structure the series" aspect. I think we shouldn't
mix in any changes that are unrelated to the BSDL reimplementation
*purpose* (as opposed to, related to the code).

Once the series is applied, in a minimal, barely working form, under the
BSDL, y'all who actually have a clue about the block layer can very
quickly improve it.

Does that sound acceptable?

Thanks!
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]