qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 1/5] block: Add blklogwrites


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 1/5] block: Add blklogwrites
Date: Fri, 1 Jun 2018 10:05:40 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/01/2018 08:31 AM, Ari Sundholm wrote:
+++ b/block/blklogwrites.c
@@ -0,0 +1,441 @@
+/*
+ * Write logging blk driver based on blkverify and blkdebug.
+ *
+ * Copyright (c) 2017 Tuomas Tynkkynen <address@hidden>
+ * Copyright (c) 2018 Aapo Vienamo <address@hidden>
+ * Copyright (c) 2018 Ari Sundholm <address@hidden>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/sockets.h" /* for EINPROGRESS on Windows */
+#include "block/block_int.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qstring.h"
+#include "qemu/cutils.h"
+#include "qemu/option.h"
+
+/* Disk format stuff - taken from Linux drivers/md/dm-log-writes.c */

Your copyright claims GPLv2+; but drivers/md/dm-log-writes.c states only "* This file is released under the GPL." - I guess that means you're okay (parts of Linux are GPLv2-only, which we can't copy into a GPLv2+ file).


I consulted legal counsel on this part, and it is our opinion that the constants and structs taken from the Linux kernel are insignificant and required for compatibility, so it should be OK to license the file as GPLv2+ in any case. Just to confirm, do you see this differently?

I'm not a lawyer, but I don't see any problem for the code you copied from that particular file (that is, any source file that says just "GPL" can be interpreted as "GPLv1+", which is therefore okay to copy into a "GPLv2+" file). I was more pointing out that in general, any time you copy code but use a different license, you DO have to perform due diligence to ensure you aren't treading on dangerous ground. And the fact that you consulted legal counsel is a good thing. If it were a more controversial claim (copying from a "GPLv2-only" file on the ground that the copied portion is part of an essential interface and therefore not bound by GPLv2-only and therefore okay for inclusion in GPLv2+, then I'd have mentioned the legal counsel's advice as part of the commit message; but in this case I don't think that's necessary. Also, we DO have files in qemu that are GPLv2-only - we don't like adding more when not necessary, but when copying from a GPLv2-only source, it is certainly a justifiable action (rather than worrying about whether licensing your file as GPLv2+ is violating the intent of the copied portions in your file) - but again, I don't see that as something needed for this patch, given that your source file did not state GPLv2-only.

Do we still want to support yet another legacy syntax addition?  I'd rather just require the user to pass in a valid --blockdev specification (which implies that you MUST support a QMP description), and skip the legacy syntax altogether.


I believe this was inherited from blkverify, which was used as a basis. I will have to do some research into how to do this properly for this kind of a driver which requires multiple filenames. Any pointers would be appreciated.


Look at qapi/block-core.json BlockdevOptionsBlkverify for how to declare the QMP type. Kevin may also have some hints.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

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