qemu-e2k/block/raw_bsd.c

266 lines
8.3 KiB
C
Raw Normal View History

add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
/* BlockDriver implementation for "raw"
*
* Copyright (C) 2010-2016 Red Hat, Inc.
* Copyright (C) 2010, Blue Swirl <blauwirbel@gmail.com>
* Copyright (C) 2009, Anthony Liguori <aliguori@us.ibm.com>
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
*
* Author:
* Laszlo Ersek <lersek@redhat.com>
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#include "qemu/osdep.h"
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
#include "block/block_int.h"
2016-03-14 09:01:28 +01:00
#include "qapi/error.h"
#include "qemu/option.h"
static QemuOptsList raw_create_opts = {
.name = "raw-create-opts",
.head = QTAILQ_HEAD_INITIALIZER(raw_create_opts.head),
.desc = {
{
.name = BLOCK_OPT_SIZE,
.type = QEMU_OPT_SIZE,
.help = "Virtual disk size"
},
{ /* end of list */ }
}
};
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
static int raw_reopen_prepare(BDRVReopenState *reopen_state,
BlockReopenQueue *queue, Error **errp)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return 0;
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int coroutine_fn raw_co_readv(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, QEMUIOVector *qiov)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
BLKDBG_EVENT(bs->file, BLKDBG_READ_AIO);
return bdrv_co_readv(bs->file, sector_num, nb_sectors, qiov);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int coroutine_fn
raw_co_writev_flags(BlockDriverState *bs, int64_t sector_num, int nb_sectors,
QEMUIOVector *qiov, int flags)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
raw: Prohibit dangerous writes for probed images If the user neglects to specify the image format, QEMU probes the image to guess it automatically, for convenience. Relying on format probing is insecure for raw images (CVE-2008-2004). If the guest writes a suitable header to the device, the next probe will recognize a format chosen by the guest. A malicious guest can abuse this to gain access to host files, e.g. by crafting a QCOW2 header with backing file /etc/shadow. Commit 1e72d3b (April 2008) provided -drive parameter format to let users disable probing. Commit f965509 (March 2009) extended QCOW2 to optionally store the backing file format, to let users disable backing file probing. QED has had a flag to suppress probing since the beginning (2010), set whenever a raw backing file is assigned. All of these additions that allow to avoid format probing have to be specified explicitly. The default still allows the attack. In order to fix this, commit 79368c8 (July 2010) put probed raw images in a restricted mode, in which they wouldn't be able to overwrite the first few bytes of the image so that they would identify as a different image. If a write to the first sector would write one of the signatures of another driver, qemu would instead zero out the first four bytes. This patch was later reverted in commit 8b33d9e (September 2010) because it didn't get the handling of unaligned qiov members right. Today's block layer that is based on coroutines and has qiov utility functions makes it much easier to get this functionality right, so this patch implements it. The other differences of this patch to the old one are that it doesn't silently write something different than the guest requested by zeroing out some bytes (it fails the request instead) and that it doesn't maintain a list of signatures in the raw driver (it calls the usual probe function instead). Note that this change doesn't introduce new breakage for false positive cases where the guest legitimately writes data into the first sector that matches the signatures of an image format (e.g. for nested virt): These cases were broken before, only the failure mode changes from corruption after the next restart (when the wrong format is probed) to failing the problematic write request. Also note that like in the original patch, the restrictions only apply if the image format has been guessed by probing. Explicitly specifying a format allows guests to write anything they like. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1416497234-29880-8-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-20 16:27:12 +01:00
void *buf = NULL;
BlockDriver *drv;
QEMUIOVector local_qiov;
int ret;
if (bs->probed && sector_num == 0) {
/* As long as these conditions are true, we can't get partial writes to
* the probe buffer and can just directly check the request. */
QEMU_BUILD_BUG_ON(BLOCK_PROBE_BUF_SIZE != 512);
QEMU_BUILD_BUG_ON(BDRV_SECTOR_SIZE != 512);
if (nb_sectors == 0) {
/* qemu_iovec_to_buf() would fail, but we want to return success
* instead of -EINVAL in this case. */
return 0;
}
buf = qemu_try_blockalign(bs->file->bs, 512);
raw: Prohibit dangerous writes for probed images If the user neglects to specify the image format, QEMU probes the image to guess it automatically, for convenience. Relying on format probing is insecure for raw images (CVE-2008-2004). If the guest writes a suitable header to the device, the next probe will recognize a format chosen by the guest. A malicious guest can abuse this to gain access to host files, e.g. by crafting a QCOW2 header with backing file /etc/shadow. Commit 1e72d3b (April 2008) provided -drive parameter format to let users disable probing. Commit f965509 (March 2009) extended QCOW2 to optionally store the backing file format, to let users disable backing file probing. QED has had a flag to suppress probing since the beginning (2010), set whenever a raw backing file is assigned. All of these additions that allow to avoid format probing have to be specified explicitly. The default still allows the attack. In order to fix this, commit 79368c8 (July 2010) put probed raw images in a restricted mode, in which they wouldn't be able to overwrite the first few bytes of the image so that they would identify as a different image. If a write to the first sector would write one of the signatures of another driver, qemu would instead zero out the first four bytes. This patch was later reverted in commit 8b33d9e (September 2010) because it didn't get the handling of unaligned qiov members right. Today's block layer that is based on coroutines and has qiov utility functions makes it much easier to get this functionality right, so this patch implements it. The other differences of this patch to the old one are that it doesn't silently write something different than the guest requested by zeroing out some bytes (it fails the request instead) and that it doesn't maintain a list of signatures in the raw driver (it calls the usual probe function instead). Note that this change doesn't introduce new breakage for false positive cases where the guest legitimately writes data into the first sector that matches the signatures of an image format (e.g. for nested virt): These cases were broken before, only the failure mode changes from corruption after the next restart (when the wrong format is probed) to failing the problematic write request. Also note that like in the original patch, the restrictions only apply if the image format has been guessed by probing. Explicitly specifying a format allows guests to write anything they like. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1416497234-29880-8-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-20 16:27:12 +01:00
if (!buf) {
ret = -ENOMEM;
goto fail;
}
ret = qemu_iovec_to_buf(qiov, 0, buf, 512);
if (ret != 512) {
ret = -EINVAL;
goto fail;
}
drv = bdrv_probe_all(buf, 512, NULL);
if (drv != bs->drv) {
ret = -EPERM;
goto fail;
}
/* Use the checked buffer, a malicious guest might be overwriting its
* original buffer in the background. */
qemu_iovec_init(&local_qiov, qiov->niov + 1);
qemu_iovec_add(&local_qiov, buf, 512);
qemu_iovec_concat(&local_qiov, qiov, 512, qiov->size - 512);
qiov = &local_qiov;
}
BLKDBG_EVENT(bs->file, BLKDBG_WRITE_AIO);
ret = bdrv_co_pwritev(bs->file, sector_num * BDRV_SECTOR_SIZE,
nb_sectors * BDRV_SECTOR_SIZE, qiov, flags);
raw: Prohibit dangerous writes for probed images If the user neglects to specify the image format, QEMU probes the image to guess it automatically, for convenience. Relying on format probing is insecure for raw images (CVE-2008-2004). If the guest writes a suitable header to the device, the next probe will recognize a format chosen by the guest. A malicious guest can abuse this to gain access to host files, e.g. by crafting a QCOW2 header with backing file /etc/shadow. Commit 1e72d3b (April 2008) provided -drive parameter format to let users disable probing. Commit f965509 (March 2009) extended QCOW2 to optionally store the backing file format, to let users disable backing file probing. QED has had a flag to suppress probing since the beginning (2010), set whenever a raw backing file is assigned. All of these additions that allow to avoid format probing have to be specified explicitly. The default still allows the attack. In order to fix this, commit 79368c8 (July 2010) put probed raw images in a restricted mode, in which they wouldn't be able to overwrite the first few bytes of the image so that they would identify as a different image. If a write to the first sector would write one of the signatures of another driver, qemu would instead zero out the first four bytes. This patch was later reverted in commit 8b33d9e (September 2010) because it didn't get the handling of unaligned qiov members right. Today's block layer that is based on coroutines and has qiov utility functions makes it much easier to get this functionality right, so this patch implements it. The other differences of this patch to the old one are that it doesn't silently write something different than the guest requested by zeroing out some bytes (it fails the request instead) and that it doesn't maintain a list of signatures in the raw driver (it calls the usual probe function instead). Note that this change doesn't introduce new breakage for false positive cases where the guest legitimately writes data into the first sector that matches the signatures of an image format (e.g. for nested virt): These cases were broken before, only the failure mode changes from corruption after the next restart (when the wrong format is probed) to failing the problematic write request. Also note that like in the original patch, the restrictions only apply if the image format has been guessed by probing. Explicitly specifying a format allows guests to write anything they like. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1416497234-29880-8-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-20 16:27:12 +01:00
fail:
if (qiov == &local_qiov) {
qemu_iovec_destroy(&local_qiov);
}
qemu_vfree(buf);
return ret;
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
int64_t sector_num,
int nb_sectors, int *pnum,
BlockDriverState **file)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
*pnum = nb_sectors;
*file = bs->file->bs;
return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_DATA |
(sector_num << BDRV_SECTOR_BITS);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int coroutine_fn raw_co_pwrite_zeroes(BlockDriverState *bs,
int64_t offset, int count,
BdrvRequestFlags flags)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_co_pwrite_zeroes(bs->file, offset, count, flags);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int coroutine_fn raw_co_discard(BlockDriverState *bs,
int64_t sector_num, int nb_sectors)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_co_discard(bs->file->bs, sector_num, nb_sectors);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int64_t raw_getlength(BlockDriverState *bs)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_getlength(bs->file->bs);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int raw_get_info(BlockDriverState *bs, BlockDriverInfo *bdi)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_get_info(bs->file->bs, bdi);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int raw_truncate(BlockDriverState *bs, int64_t offset)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_truncate(bs->file->bs, offset);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int raw_media_changed(BlockDriverState *bs)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_media_changed(bs->file->bs);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static void raw_eject(BlockDriverState *bs, bool eject_flag)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
bdrv_eject(bs->file->bs, eject_flag);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static void raw_lock_medium(BlockDriverState *bs, bool locked)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
bdrv_lock_medium(bs->file->bs, locked);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static BlockAIOCB *raw_aio_ioctl(BlockDriverState *bs,
unsigned long int req, void *buf,
BlockCompletionFunc *cb,
void *opaque)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_aio_ioctl(bs->file->bs, req, buf, cb, opaque);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int raw_has_zero_init(BlockDriverState *bs)
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
{
return bdrv_has_zero_init(bs->file->bs);
add skeleton for BSD licensed "raw" BlockDriver On 08/05/13 15:03, Paolo Bonzini wrote: > > > ----- Original Message ----- >> From: "Laszlo Ersek" <lersek@redhat.com> >> To: "Paolo Bonzini" <pbonzini@redhat.com> >> Sent: Monday, August 5, 2013 2:43:46 PM >> Subject: Re: [PATCH 1/2] raw: add license header >> >> On 08/02/13 00:27, Paolo Bonzini wrote: >>> On 08/01/2013 10:13 AM, Christoph Hellwig wrote: >>>> On Wed, Jul 31, 2013 at 08:19:51AM +0200, Paolo Bonzini wrote: >>>>> Most of the block layer is under the BSD license, thus it is >>>>> reasonable to license block/raw.c the same way. CCed people should >>>>> ACK by replying with a Signed-off-by line. >>>> >>>> The coded was intended to be GPLv2. >>> >>> Laszlo, would you be willing to do clean-room reverse engineering? >>> >>> (No rants, please. :)) >> >> What's the scope exactly? > > It's quite small, it's a file full of forwarders like > > static void raw_foo(BlockDriverState *bs) > { > return bdrv_foo(bs->file); > } > > It's 170 lines of code, all as boring as this. I only picked you > because I'm quite certain you have never seen the file (and the answer > confirmed it). > > Basically: > > 1) BlockDriver is a struct in which these function members are > interesting: > > .bdrv_reopen_prepare > .bdrv_co_readv > .bdrv_co_writev > .bdrv_co_is_allocated > .bdrv_co_write_zeroes > .bdrv_co_discard > .bdrv_getlength > .bdrv_get_info > .bdrv_truncate > .bdrv_is_inserted > .bdrv_media_changed > .bdrv_eject > .bdrv_lock_medium > .bdrv_ioctl > .bdrv_aio_ioctl > .bdrv_has_zero_init > > They should be implemented as simple forwarders (see above). > There are 16 functions listed here, you can easily see how this > already accounts for 100+ SLOC roughly... > > The implementations of bdrv_co_readv and bdrv_co_writev should also > call BLKDBG_EVENT on bs->file too, before forwarding to bs->file. The > events to be generated are BLKDBG_READ_AIO and BLKDBG_WRITE_AIO. > > 2) This is also a simple forwarder function: > > .bdrv_create > > but there is no BlockDriverState argument so the forwarded-to function > does not have a bs->file argument either. The forwarded-to function > is bdrv_create_file. > > 3) These members are special > > .format_name is the string "raw" > .bdrv_open raw_open should set bs->sg to bs->file->sg and return 0 > .bdrv_close raw_close should do nothing > .bdrv_probe raw_probe should just return 1. > > 4) There is another member, .create_options, which is an array of > QEMUOptionParameter structs, terminated by an all-zero item. The only > option you need is for the virtual disk size. You will find something > to copy from in other block drivers, for example block/qcow2.c. > > 5) Formats are registered with bdrv_register (takes a BlockDriver*). > You also need to pass the caller of bdrv_register to block_init. > > 6) I'm not sure how to organize the patch series, so I'll leave this to > your creativity. I guess in this case move/copy detection of git should > be disabled. I would definitely include this spec in the commit > message as a proof of clean-room reverse engineering. > > 7) Remember a BSD header like the one in block.c. > > Paolo This patch implements the email up to the paragraph ending with "100+ SLOC roughly". The skeleton is generated from the list there, with a simple shell loop using "sed" and the raw_foo() template. The BSD license block is copied (and reflowed) from "util/qemu-progress.c". Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-08-21 12:41:17 +02:00
}
static int raw_create(const char *filename, QemuOpts *opts, Error **errp)
{
return bdrv_create_file(filename, opts, errp);
}
static int raw_open(BlockDriverState *bs, QDict *options, int flags,
Error **errp)
{
bs->sg = bs->file->bs->sg;
bs->supported_write_flags = BDRV_REQ_FUA;
block: Honor BDRV_REQ_FUA during write_zeroes The block layer has a couple of cases where it can lose Force Unit Access semantics when writing a large block of zeroes, such that the request returns before the zeroes have been guaranteed to land on underlying media. SCSI does not support FUA during WRITESAME(10/16); FUA is only supported if it falls back to WRITE(10/16). But where the underlying device is new enough to not need a fallback, it means that any upper layer request with FUA semantics was silently ignoring BDRV_REQ_FUA. Conversely, NBD has situations where it can support FUA but not ZERO_WRITE; when that happens, the generic block layer fallback to bdrv_driver_pwritev() (or the older bdrv_co_writev() in qemu 2.6) was losing the FUA flag. The problem of losing flags unrelated to ZERO_WRITE has been latent in bdrv_co_do_write_zeroes() since commit aa7bfbff, but back then, it did not matter because there was no FUA flag. It became observable when commit 93f5e6d8 paved the way for flags that can impact correctness, when we should have been using bdrv_co_writev_flags() with modified flags. Compare to commit 9eeb6dd, which got flag manipulation right in bdrv_co_do_zero_pwritev(). Symptoms: I tested with qemu-io with default writethrough cache (which is supposed to use FUA semantics on every write), and targetted an NBD client connected to a server that intentionally did not advertise NBD_FLAG_SEND_FUA. When doing 'write 0 512', the NBD client sent two operations (NBD_CMD_WRITE then NBD_CMD_FLUSH) to get the fallback FUA semantics; but when doing 'write -z 0 512', the NBD client sent only NBD_CMD_WRITE. The fix is do to a cleanup bdrv_co_flush() at the end of the operation if any step in the middle relied on a BDS that does not natively support FUA for that step (note that we don't need to flush after every operation, if the operation is broken into chunks based on bounce-buffer sizing). Each BDS gains a new flag .supported_zero_flags, which parallels the use of .supported_write_flags but only when accessing a zero write operation (the flags MUST be different, because of SCSI having different semantics based on WRITE vs. WRITESAME; and also because BDRV_REQ_MAY_UNMAP only makes sense on zero writes). Also fix some documentation to describe -ENOTSUP semantics, particularly since iscsi depends on those semantics. Down the road, we may want to add a driver where its .bdrv_co_pwritev() honors all three of BDRV_REQ_FUA, BDRV_REQ_ZERO_WRITE, and BDRV_REQ_MAY_UNMAP, and advertise this via bs->supported_write_flags for blocks opened by that driver; such a driver should NOT supply .bdrv_co_write_zeroes nor .supported_zero_flags. But none of the drivers touched in this patch want to do that (the act of writing zeroes is different enough from normal writes to deserve a second callback). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-05-04 00:39:07 +02:00
bs->supported_zero_flags = BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP;
raw: Prohibit dangerous writes for probed images If the user neglects to specify the image format, QEMU probes the image to guess it automatically, for convenience. Relying on format probing is insecure for raw images (CVE-2008-2004). If the guest writes a suitable header to the device, the next probe will recognize a format chosen by the guest. A malicious guest can abuse this to gain access to host files, e.g. by crafting a QCOW2 header with backing file /etc/shadow. Commit 1e72d3b (April 2008) provided -drive parameter format to let users disable probing. Commit f965509 (March 2009) extended QCOW2 to optionally store the backing file format, to let users disable backing file probing. QED has had a flag to suppress probing since the beginning (2010), set whenever a raw backing file is assigned. All of these additions that allow to avoid format probing have to be specified explicitly. The default still allows the attack. In order to fix this, commit 79368c8 (July 2010) put probed raw images in a restricted mode, in which they wouldn't be able to overwrite the first few bytes of the image so that they would identify as a different image. If a write to the first sector would write one of the signatures of another driver, qemu would instead zero out the first four bytes. This patch was later reverted in commit 8b33d9e (September 2010) because it didn't get the handling of unaligned qiov members right. Today's block layer that is based on coroutines and has qiov utility functions makes it much easier to get this functionality right, so this patch implements it. The other differences of this patch to the old one are that it doesn't silently write something different than the guest requested by zeroing out some bytes (it fails the request instead) and that it doesn't maintain a list of signatures in the raw driver (it calls the usual probe function instead). Note that this change doesn't introduce new breakage for false positive cases where the guest legitimately writes data into the first sector that matches the signatures of an image format (e.g. for nested virt): These cases were broken before, only the failure mode changes from corruption after the next restart (when the wrong format is probed) to failing the problematic write request. Also note that like in the original patch, the restrictions only apply if the image format has been guessed by probing. Explicitly specifying a format allows guests to write anything they like. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1416497234-29880-8-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-20 16:27:12 +01:00
if (bs->probed && !bdrv_is_read_only(bs)) {
fprintf(stderr,
"WARNING: Image format was not specified for '%s' and probing "
"guessed raw.\n"
" Automatically detecting the format is dangerous for "
"raw images, write operations on block 0 will be restricted.\n"
" Specify the 'raw' format explicitly to remove the "
"restrictions.\n",
bs->file->bs->filename);
raw: Prohibit dangerous writes for probed images If the user neglects to specify the image format, QEMU probes the image to guess it automatically, for convenience. Relying on format probing is insecure for raw images (CVE-2008-2004). If the guest writes a suitable header to the device, the next probe will recognize a format chosen by the guest. A malicious guest can abuse this to gain access to host files, e.g. by crafting a QCOW2 header with backing file /etc/shadow. Commit 1e72d3b (April 2008) provided -drive parameter format to let users disable probing. Commit f965509 (March 2009) extended QCOW2 to optionally store the backing file format, to let users disable backing file probing. QED has had a flag to suppress probing since the beginning (2010), set whenever a raw backing file is assigned. All of these additions that allow to avoid format probing have to be specified explicitly. The default still allows the attack. In order to fix this, commit 79368c8 (July 2010) put probed raw images in a restricted mode, in which they wouldn't be able to overwrite the first few bytes of the image so that they would identify as a different image. If a write to the first sector would write one of the signatures of another driver, qemu would instead zero out the first four bytes. This patch was later reverted in commit 8b33d9e (September 2010) because it didn't get the handling of unaligned qiov members right. Today's block layer that is based on coroutines and has qiov utility functions makes it much easier to get this functionality right, so this patch implements it. The other differences of this patch to the old one are that it doesn't silently write something different than the guest requested by zeroing out some bytes (it fails the request instead) and that it doesn't maintain a list of signatures in the raw driver (it calls the usual probe function instead). Note that this change doesn't introduce new breakage for false positive cases where the guest legitimately writes data into the first sector that matches the signatures of an image format (e.g. for nested virt): These cases were broken before, only the failure mode changes from corruption after the next restart (when the wrong format is probed) to failing the problematic write request. Also note that like in the original patch, the restrictions only apply if the image format has been guessed by probing. Explicitly specifying a format allows guests to write anything they like. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1416497234-29880-8-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-20 16:27:12 +01:00
}
return 0;
}
static void raw_close(BlockDriverState *bs)
{
}
static int raw_probe(const uint8_t *buf, int buf_size, const char *filename)
{
/* smallest possible positive score so that raw is used if and only if no
* other block driver works
*/
return 1;
}
static int raw_probe_blocksizes(BlockDriverState *bs, BlockSizes *bsz)
{
return bdrv_probe_blocksizes(bs->file->bs, bsz);
}
static int raw_probe_geometry(BlockDriverState *bs, HDGeometry *geo)
{
return bdrv_probe_geometry(bs->file->bs, geo);
}
BlockDriver bdrv_raw = {
.format_name = "raw",
.bdrv_probe = &raw_probe,
.bdrv_reopen_prepare = &raw_reopen_prepare,
.bdrv_open = &raw_open,
.bdrv_close = &raw_close,
.bdrv_create = &raw_create,
.bdrv_co_readv = &raw_co_readv,
.bdrv_co_writev_flags = &raw_co_writev_flags,
.bdrv_co_pwrite_zeroes = &raw_co_pwrite_zeroes,
.bdrv_co_discard = &raw_co_discard,
.bdrv_co_get_block_status = &raw_co_get_block_status,
.bdrv_truncate = &raw_truncate,
.bdrv_getlength = &raw_getlength,
2013-10-29 12:18:58 +01:00
.has_variable_length = true,
.bdrv_get_info = &raw_get_info,
.bdrv_probe_blocksizes = &raw_probe_blocksizes,
.bdrv_probe_geometry = &raw_probe_geometry,
.bdrv_media_changed = &raw_media_changed,
.bdrv_eject = &raw_eject,
.bdrv_lock_medium = &raw_lock_medium,
.bdrv_aio_ioctl = &raw_aio_ioctl,
.create_opts = &raw_create_opts,
.bdrv_has_zero_init = &raw_has_zero_init
};
static void bdrv_raw_init(void)
{
bdrv_register(&bdrv_raw);
}
block_init(bdrv_raw_init);