Am Montag 17 Oktober 2011, 19:46:11 schrieb Stefan Weil:
> So let's start. For any of my contributions, I agree to GPL v2 or later.
> Later generations should have the possibility to replace GPL v2 by
> something which matches future requirements.
I agree to GPL v2 or later.
--
Michael
Am 25.10.2011 16:34, schrieb Dor Laor:
On 10/18/2011 03:03 PM, Anthony Liguori wrote:
Okay, let's get serious about it. I set up the following wiki page for
coordination:
http://wiki.qemu.org/Relicensing
Please get the appropriate approval at Red Hat, and follow the
ACK for *@redhat.com
in
On 10/18/2011 03:03 PM, Anthony Liguori wrote:
On 10/18/2011 03:01 AM, Markus Armbruster wrote:
Avi Kivity writes:
On 10/17/2011 07:46 PM, Stefan Weil wrote:
So let's start. For any of my contributions, I agree to GPL v2 or
later.
Later generations should have the possibility to replace GPL
On Tue, Oct 18, 2011 at 4:37 PM, Paolo Bonzini wrote:
> On 10/18/2011 06:01 PM, Anthony Liguori wrote:
>>
>> Unless we split linux-user off into a separate repository. The only
>> real code sharing is TCG. I can imagine a world where TCG lived in a
>> separate repo along with qemu-system and li
On 10/18/2011 06:01 PM, Anthony Liguori wrote:
Unless we split linux-user off into a separate repository. The only
real code sharing is TCG. I can imagine a world where TCG lived in a
separate repo along with qemu-system and linux-user. Both repos could
pull in TCG as a submodule.
Nah, the
On 18 October 2011 17:30, Anthony Liguori wrote:
>
> TCG can have a debug mode that makes it GPLv3 (using the binutils code).
> You wouldn't be able to consume this debug mode with linux-user.
>
> Probably safest thing is to put disas only in qemu-system. linux-user would
> have to log hex.
Yuc
On 10/18/2011 11:15 AM, Peter Maydell wrote:
On 18 October 2011 17:01, Anthony Liguori wrote:
Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause.
Unless we split linux-user off into a separate repository. The only real
code sharing is TCG.
...and the binutils disassembl
On 10/18/2011 06:15 PM, Peter Maydell wrote:
> On 18 October 2011 17:01, Anthony Liguori wrote:
> > Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause.
> >
> > Unless we split linux-user off into a separate repository. The only real
> > code sharing is TCG.
>
> ...and the bin
On 10/18/2011 10:31 AM, Paolo Bonzini wrote:
On 10/18/2011 05:19 PM, Peter Maydell wrote:
On 18 October 2011 14:03, Anthony Liguori wrote:
Okay, let's get serious about it. I set up the following wiki page for
coordination:
http://wiki.qemu.org/Relicensing
This says:
use the following git co
On 18 October 2011 17:01, Anthony Liguori wrote:
> Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause.
>
> Unless we split linux-user off into a separate repository. The only real
> code sharing is TCG.
...and the binutils disassembly code, which is the reason we wanted
to m
On 18 October 2011 16:56, Anthony Liguori wrote:
> On 10/18/2011 10:19 AM, Peter Maydell wrote:
>> which (apart from having a typo) only lists the people who were
>> the git commit authors. This isn't the same as everybody who might
>> have copyright on the change. There are certainly commits in t
On 10/18/2011 10:19 AM, Peter Maydell wrote:
On 18 October 2011 14:03, Anthony Liguori wrote:
Okay, let's get serious about it. I set up the following wiki page for
coordination:
http://wiki.qemu.org/Relicensing
This says:
use the following git command to get a list of authors:
git log --f
On 10/18/2011 05:19 PM, Peter Maydell wrote:
On 18 October 2011 14:03, Anthony Liguori wrote:
Okay, let's get serious about it. I set up the following wiki page for
coordination:
http://wiki.qemu.org/Relicensing
This says:
use the following git command to get a list of authors:
git log --f
On 18 October 2011 14:03, Anthony Liguori wrote:
> Okay, let's get serious about it. I set up the following wiki page for
> coordination:
>
> http://wiki.qemu.org/Relicensing
This says:
use the following git command to get a list of authors:
git log --format:"%an <%ae>" -- file.c
which (apart
On 18 October 2011 15:03, Anthony Liguori wrote:
> Okay, let's get serious about it. I set up the following wiki page for
> coordination:
>
> http://wiki.qemu.org/Relicensing
The bottom section with "some SVN authors" has a bunch of files by me
that are "GPLv2". Most of them were probably meant
t;Blue
> Swirl" , "Max Filippov" , "Avi Kivity" , "Paolo Bonzini"
> Objet : Re: [Qemu-devel] GPLv3 troubles
>
> On 10/18/2011 09:33 AM, Andreas Färber wrote:
> > Am 18.10.2011 15:03, schrieb Anthony Liguori:
> >> Okay, let
On 10/18/2011 09:33 AM, Andreas Färber wrote:
Am 18.10.2011 15:03, schrieb Anthony Liguori:
Okay, let's get serious about it. I set up the following wiki page for
coordination:
http://wiki.qemu.org/Relicensing
Please get the appropriate approval at Red Hat, and follow the
instructions on the
Am 18.10.2011 15:03, schrieb Anthony Liguori:
> Okay, let's get serious about it. I set up the following wiki page for
> coordination:
>
> http://wiki.qemu.org/Relicensing
>
> Please get the appropriate approval at Red Hat, and follow the
> instructions on the wiki. I'm in the process of gettin
On 10/18/2011 03:01 AM, Markus Armbruster wrote:
Avi Kivity writes:
On 10/17/2011 07:46 PM, Stefan Weil wrote:
So let's start. For any of my contributions, I agree to GPL v2 or later.
Later generations should have the possibility to replace GPL v2 by
something which matches future requiremen
Avi Kivity writes:
> On 10/17/2011 07:46 PM, Stefan Weil wrote:
>>
>> So let's start. For any of my contributions, I agree to GPL v2 or later.
>> Later generations should have the possibility to replace GPL v2 by
>> something which matches future requirements.
>
> I expect Red Hat contributions c
On 10/17/2011 07:46 PM, Stefan Weil wrote:
>
> So let's start. For any of my contributions, I agree to GPL v2 or later.
> Later generations should have the possibility to replace GPL v2 by
> something which matches future requirements.
I expect Red Hat contributions can be relicensed to v2+ as wel
On Mon, Oct 17, 2011 at 4:51 PM, Anthony Liguori wrote:
> On 10/17/2011 11:47 AM, Peter Maydell wrote:
>>
>> On 17 October 2011 17:39, Andreas Färber wrote:
>>>
>>> Am 17.10.2011 13:10, schrieb Paolo Bonzini:
Making a list of GPLv2 files would be a start, though.
>>>
>>> grep -r version
On Mon, Oct 17, 2011 at 6:29 PM, Anthony Liguori wrote:
> On 10/17/2011 01:20 PM, Stefan Weil wrote:
>>
>> Am 17.10.2011 20:16, schrieb Anthony Liguori:
>>>
>>> On 10/17/2011 12:58 PM, Andreas Färber wrote:
Am 17.10.2011 18:51, schrieb Anthony Liguori:
>
> Including binutils code
On Mon, Oct 17, 2011 at 5:46 PM, Stefan Weil wrote:
> Am 17.10.2011 18:47, schrieb Anthony Liguori:
>>
>> On 10/17/2011 11:30 AM, Andreas Färber wrote:
>>>
>>> Am 17.10.2011 16:17, schrieb Anthony Liguori:
On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
>
> On 10/17/2011 02:38 PM, A
On 10/17/2011 01:34 PM, Peter Maydell wrote:
On 17 October 2011 19:29, Anthony Liguori wrote:
Likewise, we could add tracing to translate.c to achieve the same affect as
in_asm.
Having the code you're trying to debug be also doing the printing out
of the disassembly seems like a recipe for co
On 17 October 2011 19:29, Anthony Liguori wrote:
> Likewise, we could add tracing to translate.c to achieve the same affect as
> in_asm.
Having the code you're trying to debug be also doing the printing out
of the disassembly seems like a recipe for confusing yourself (because
you lose the indepe
On 10/17/2011 01:20 PM, Stefan Weil wrote:
Am 17.10.2011 20:16, schrieb Anthony Liguori:
On 10/17/2011 12:58 PM, Andreas Färber wrote:
Am 17.10.2011 18:51, schrieb Anthony Liguori:
Including binutils code is just a bad idea.
Do you see a real alternative? Would it be possible to pipe machine
Am 17.10.2011 20:16, schrieb Anthony Liguori:
On 10/17/2011 12:58 PM, Andreas Färber wrote:
Am 17.10.2011 18:51, schrieb Anthony Liguori:
Including binutils code is just a bad idea.
Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassemble
On 17 October 2011 19:16, Anthony Liguori wrote:
> On 10/17/2011 12:58 PM, Andreas Färber wrote:
>> Do you see a real alternative? Would it be possible to pipe machine code
>> from QEMU into an external disassembler?
>
> Sure. This is only used in the monitor for interactive debugging, right?
Al
On 10/17/2011 12:58 PM, Andreas Färber wrote:
Am 17.10.2011 18:51, schrieb Anthony Liguori:
Including binutils code is just a bad idea.
Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?
Sure. This is only used in the monitor fo
Am 17.10.2011 18:51, schrieb Anthony Liguori:
> Including binutils code is just a bad idea.
Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn
Am 17.10.2011 18:47, schrieb Anthony Liguori:
> It's not something that any one person can really change. It would
> require a very large effort. To give you an idea of the scope, I ran
> the following command:
>
> $ grep GPL *.c hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u |
> while rea
Am 17.10.2011 18:47, schrieb Anthony Liguori:
On 10/17/2011 11:30 AM, Andreas Färber wrote:
Am 17.10.2011 16:17, schrieb Anthony Liguori:
On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
On 10/17/2011 02:38 PM, Anthony Liguori wrote:
Could we please draft some policy on this? This is not a GDB is
Am 17.10.2011 18:47, schrieb Peter Maydell:
> On 17 October 2011 17:39, Andreas Färber wrote:
>> Am 17.10.2011 13:10, schrieb Paolo Bonzini:
>>> Making a list of GPLv2 files would be a start, though.
>>
>> grep -r version *.c comes up with these:
>
> Your rune needs tweaking -- it isn't looking i
On 10/17/2011 11:47 AM, Peter Maydell wrote:
On 17 October 2011 17:39, Andreas Färber wrote:
Am 17.10.2011 13:10, schrieb Paolo Bonzini:
Making a list of GPLv2 files would be a start, though.
grep -r version *.c comes up with these:
Your rune needs tweaking -- it isn't looking inside any
s
On 17 October 2011 17:39, Andreas Färber wrote:
> Am 17.10.2011 13:10, schrieb Paolo Bonzini:
>> Making a list of GPLv2 files would be a start, though.
>
> grep -r version *.c comes up with these:
Your rune needs tweaking -- it isn't looking inside any
subdirectories.
-- PMM
Am 17.10.2011 13:10, schrieb Paolo Bonzini:
> Making a list of GPLv2 files would be a start, though.
grep -r version *.c comes up with these:
v2 only:
aio.c
block-migration.c
buffered_file.c
compatfd.c
error.c
iov.c
kvm-all.c
memory.c
migration.c
migration-exec.c
migration-fd.c
migration-tcp.c
mi
Am 17.10.2011 16:17, schrieb Anthony Liguori:
> On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
>> On 10/17/2011 02:38 PM, Anthony Liguori wrote:
Could we please draft some policy on this? This is not a GDB issue,
it's
very general. Whether we like it or not, there is GPLv3-licensed cod
On 10/17/2011 04:17 PM, Anthony Liguori wrote:
License fragmentation with respect to the de facto standard toolchain
(binutils)
is wrong.
Fragmentation with respect to the de factor standard kernel (Linux) is
wrong. We currently pull in code (mostly headers, although not exclusively)
from Li
On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
On 10/17/2011 02:38 PM, Anthony Liguori wrote:
Could we please draft some policy on this? This is not a GDB issue, it's
very general. Whether we like it or not, there is GPLv3-licensed code
and there will probably be a GPLv4 one day.
I don't see any
On 10/17/2011 02:38 PM, Anthony Liguori wrote:
Could we please draft some policy on this? This is not a GDB issue, it's
very general. Whether we like it or not, there is GPLv3-licensed code
and there will probably be a GPLv4 one day.
I don't see anything wrong with GPLv2 only. While I don't th
On 10/17/2011 05:45 AM, Andreas Färber wrote:
Am 15.10.2011 11:02, schrieb Blue Swirl:
On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov wrote:
diff --git a/target-xtensa/core-fsf/gdb-config.c
b/target-xtensa/core-fsf/gdb-config.c
new file mode 100644
index 000..6705d9c
--- /dev/null
+++ b/ta
On 10/17/2011 01:07 PM, Andreas Färber wrote:
> That is close to impossible, you usually ask permission for all the
> authors in the history to avoid bigger problems.
I did refer to authors in history, in case that was unclear.
Authors in history (unlike authors in git blame, but you cannot
Am 17.10.2011 12:47, schrieb Paolo Bonzini:
> On 10/17/2011 12:45 PM, Andreas Färber wrote:
>> Could we please draft some policy on this? This is not a GDB issue, it's
>> very general. Whether we like it or not, there is GPLv3-licensed code
>> and there will probably be a GPLv4 one day.
>>
>> IMO h
On 10/17/2011 12:45 PM, Andreas Färber wrote:
Could we please draft some policy on this? This is not a GDB issue, it's
very general. Whether we like it or not, there is GPLv3-licensed code
and there will probably be a GPLv4 one day.
IMO having old GPLv2-only code is one thing. But there's a lot
Am 15.10.2011 11:02, schrieb Blue Swirl:
> On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov wrote:
>> diff --git a/target-xtensa/core-fsf/gdb-config.c
>> b/target-xtensa/core-fsf/gdb-config.c
>> new file mode 100644
>> index 000..6705d9c
>> --- /dev/null
>> +++ b/target-xtensa/core-fsf/gdb-confi
46 matches
Mail list logo
