qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Better support for dma_addr_t variables


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH] Better support for dma_addr_t variables
Date: Wed, 4 Apr 2012 10:12:58 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Apr 03, 2012 at 10:53:10AM +0200, Andreas Färber wrote:
> Am 03.04.2012 02:51, schrieb David Gibson:
> > On Mon, Apr 02, 2012 at 09:49:12AM +0200, Andreas Färber wrote:
> >> Am 31.03.2012 10:50, schrieb David Gibson:
> >>> On Fri, Mar 30, 2012 at 11:34:25AM +0200, Andreas Färber wrote:
> >>>> Am 30.03.2012 11:32, schrieb Andreas Färber:
> >>>>> Am 27.03.2012 04:43, schrieb David Gibson:
> >>>>>> diff --git a/hw/qdev-dma.h b/hw/qdev-dma.h
> >>>>>> new file mode 100644
> >>>>>> index 0000000..e407771
> >>>>>> --- /dev/null
> >>>>>> +++ b/hw/qdev-dma.h
> >>>>>> @@ -0,0 +1,4 @@
> >>>>>> +#include "qdev-addr.h"
> >>>>>> +
> >>>>>> +#define DEFINE_PROP_DMAADDR(_n, _s, _f, _d)                           
> >>>>>>     \
> >>>>>> +    DEFINE_PROP_TADDR(_n, _s, _f, _d)
> >>>>>
> >>>>> Is a new header just for this really needed? It's not being used in this
> >>>>> patch, so its necessity is hard to judge. ;)
> >>>>
> >>>> Additionally it's missing a license notice.
> >>>
> >>> Just like qdev-addr.h.  And qdev.h for that matter.
> >>>
> >>> You seriously want a license notice for two lines of trivial macro?
> >>
> >> Yes, the issue here is under what license the file is. It's a new file,
> >> so in lack of a license statement is it under GPLv2 because QEMU as a
> >> whole currently is?  Thus a header explicitly saying that it's under
> >> GPLv2+ (or BSD or MIT/X11 or ...) would be appreciated to avoid further
> >> complications. Compare our GPLv2+ relicensing page:
> >>
> >> http://wiki.qemu.org/Relicensing
> > 
> > It's 4 trivial lines.  Well under the copyrightability threshold even
> > by the paranoid estimates of IBM Legal.
> 
> Tell that to your IBM colleague. We had an argument about 1 line of
> trivial code replacement (not even new code) that kept us from
> relicensing target-unicore32/helper.c just recently.
> This is not me who's being paranoid about lines of code, really. I've
> even heard that header files may not even be the subject of licenses at
> all in some legislations. I'm just picky and sometimes spot the odd sock
> from afar. ;)

Sigh.  Okay.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson




reply via email to

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