[6/7] target-xtensa: add fsf core

Message ID	1318213565-3268-7-git-send-email-jcmvbkbc@gmail.com
State	New
Headers	show Return-Path: <qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org> From: Max Filippov <jcmvbkbc@gmail.com> To: qemu-devel@nongnu.org Date: Mon, 10 Oct 2011 06:26:04 +0400 Message-Id: <1318213565-3268-7-git-send-email-jcmvbkbc@gmail.com> In-Reply-To: <1318213565-3268-1-git-send-email-jcmvbkbc@gmail.com> References: <1318213565-3268-1-git-send-email-jcmvbkbc@gmail.com> Cc: jcmvbkbc@gmail.com Subject: [Qemu-devel] [PATCH 6/7] target-xtensa: add fsf core Precedence: list Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org

Max Filippov Oct. 10, 2011, 2:26 a.m. UTC

This is FSF big endian core implemented through linux/gdb overlay.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 Makefile.target                     |    1 +
 target-xtensa/core-fsf.c            |   28 +++
 target-xtensa/core-fsf/core-isa.h   |  362 +++++++++++++++++++++++++++++++++++
 target-xtensa/core-fsf/gdb-config.c |  152 +++++++++++++++
 4 files changed, 543 insertions(+), 0 deletions(-)
 create mode 100644 target-xtensa/core-fsf.c
 create mode 100644 target-xtensa/core-fsf/core-isa.h
 create mode 100644 target-xtensa/core-fsf/gdb-config.c

Blue Swirl Oct. 15, 2011, 9:02 a.m. UTC | #1

On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> This is FSF big endian core implemented through linux/gdb overlay.
>
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
>  Makefile.target                     |    1 +
>  target-xtensa/core-fsf.c            |   28 +++
>  target-xtensa/core-fsf/core-isa.h   |  362 +++++++++++++++++++++++++++++++++++
>  target-xtensa/core-fsf/gdb-config.c |  152 +++++++++++++++
>  4 files changed, 543 insertions(+), 0 deletions(-)
>  create mode 100644 target-xtensa/core-fsf.c
>  create mode 100644 target-xtensa/core-fsf/core-isa.h
>  create mode 100644 target-xtensa/core-fsf/gdb-config.c
>
> diff --git a/Makefile.target b/Makefile.target
> index 4539824..819f42f 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -373,6 +373,7 @@ obj-xtensa-y += xtensa_pic.o
>  obj-xtensa-y += xtensa_dc232b.o
>  obj-xtensa-y += xtensa-semi.o
>  obj-xtensa-y += core-dc232b.o
> +obj-xtensa-y += core-fsf.o
>
>  main.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
>
> diff --git a/target-xtensa/core-fsf.c b/target-xtensa/core-fsf.c
> new file mode 100644
> index 0000000..f22dbb5
> --- /dev/null
> +++ b/target-xtensa/core-fsf.c
> @@ -0,0 +1,28 @@
> +#include "cpu.h"
> +#include "exec-all.h"
> +#include "gdbstub.h"
> +#include "qemu-common.h"
> +#include "host-utils.h"
> +
> +#include "core-fsf/core-isa.h"
> +#include "overlay_tool.h"
> +
> +static const XtensaConfig fsf = {
> +    .name = "fsf",
> +    .options = XTENSA_OPTIONS,
> +    .gdb_regmap = {
> +        .num_regs = 130,
> +        .num_core_regs = 75,
> +        .reg = {
> +#include "core-fsf/gdb-config.c"
> +        }
> +    },
> +    .nareg = XCHAL_NUM_AREGS,
> +    .ndepc = 1,
> +    EXCEPTIONS_SECTION,
> +    INTERRUPTS_SECTION,
> +    TLB_SECTION,
> +    .clock_freq_khz = 10000,
> +};
> +
> +REGISTER_CORE(fsf)
> diff --git a/target-xtensa/core-fsf/core-isa.h b/target-xtensa/core-fsf/core-isa.h
> new file mode 100644
> index 0000000..57d1870
> --- /dev/null
> +++ b/target-xtensa/core-fsf/core-isa.h
> @@ -0,0 +1,362 @@
> +/*
> + * Xtensa processor core configuration information.
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 1999-2006 Tensilica Inc.
> + */
> +
> +#ifndef _XTENSA_CORE_H
> +#define _XTENSA_CORE_H
> +
> +
> +/****************************************************************************
> +           Parameters Useful for Any Code, USER or PRIVILEGED
> + ****************************************************************************/
> +
> +/*
> + *  Note:  Macros of the form XCHAL_HAVE_*** have a value of 1 if the option is
> + *  configured, and a value of 0 otherwise.  These macros are always defined.
> + */
> +
> +
> +/*----------------------------------------------------------------------
> +                               ISA
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_HAVE_BE                  1       /* big-endian byte ordering */
> +#define XCHAL_HAVE_WINDOWED            1       /* windowed registers option */
> +#define XCHAL_NUM_AREGS                        64      /* num of physical addr regs */
> +#define XCHAL_NUM_AREGS_LOG2           6       /* log2(XCHAL_NUM_AREGS) */
> +#define XCHAL_MAX_INSTRUCTION_SIZE     3       /* max instr bytes (3..8) */
> +#define XCHAL_HAVE_DEBUG               1       /* debug option */
> +#define XCHAL_HAVE_DENSITY             1       /* 16-bit instructions */
> +#define XCHAL_HAVE_LOOPS               1       /* zero-overhead loops */
> +#define XCHAL_HAVE_NSA                 1       /* NSA/NSAU instructions */
> +#define XCHAL_HAVE_MINMAX              0       /* MIN/MAX instructions */
> +#define XCHAL_HAVE_SEXT                        0       /* SEXT instruction */
> +#define XCHAL_HAVE_CLAMPS              0       /* CLAMPS instruction */
> +#define XCHAL_HAVE_MUL16               0       /* MUL16S/MUL16U instructions */
> +#define XCHAL_HAVE_MUL32               0       /* MULL instruction */
> +#define XCHAL_HAVE_MUL32_HIGH          0       /* MULUH/MULSH instructions */
> +#define XCHAL_HAVE_L32R                        1       /* L32R instruction */
> +#define XCHAL_HAVE_ABSOLUTE_LITERALS   1       /* non-PC-rel (extended) L32R */
> +#define XCHAL_HAVE_CONST16             0       /* CONST16 instruction */
> +#define XCHAL_HAVE_ADDX                        1       /* ADDX#/SUBX# instructions */
> +#define XCHAL_HAVE_WIDE_BRANCHES       0       /* B*.W18 or B*.W15 instr's */
> +#define XCHAL_HAVE_PREDICTED_BRANCHES  0       /* B[EQ/EQZ/NE/NEZ]T instr's */
> +#define XCHAL_HAVE_CALL4AND12          1       /* (obsolete option) */
> +#define XCHAL_HAVE_ABS                 1       /* ABS instruction */
> +/*#define XCHAL_HAVE_POPC              0*/     /* POPC instruction */
> +/*#define XCHAL_HAVE_CRC               0*/     /* CRC instruction */
> +#define XCHAL_HAVE_RELEASE_SYNC                0       /* L32AI/S32RI instructions */
> +#define XCHAL_HAVE_S32C1I              0       /* S32C1I instruction */
> +#define XCHAL_HAVE_SPECULATION         0       /* speculation */
> +#define XCHAL_HAVE_FULL_RESET          1       /* all regs/state reset */
> +#define XCHAL_NUM_CONTEXTS             1       /* */
> +#define XCHAL_NUM_MISC_REGS            2       /* num of scratch regs (0..4) */
> +#define XCHAL_HAVE_TAP_MASTER          0       /* JTAG TAP control instr's */
> +#define XCHAL_HAVE_PRID                        1       /* processor ID register */
> +#define XCHAL_HAVE_THREADPTR           1       /* THREADPTR register */
> +#define XCHAL_HAVE_BOOLEANS            0       /* boolean registers */
> +#define XCHAL_HAVE_CP                  0       /* CPENABLE reg (coprocessor) */
> +#define XCHAL_CP_MAXCFG                        0       /* max allowed cp id plus one */
> +#define XCHAL_HAVE_MAC16               0       /* MAC16 package */
> +#define XCHAL_HAVE_VECTORFPU2005       0       /* vector floating-point pkg */
> +#define XCHAL_HAVE_FP                  0       /* floating point pkg */
> +#define XCHAL_HAVE_VECTRA1             0       /* Vectra I  pkg */
> +#define XCHAL_HAVE_VECTRALX            0       /* Vectra LX pkg */
> +#define XCHAL_HAVE_HIFI2               0       /* HiFi2 Audio Engine pkg */
> +
> +
> +/*----------------------------------------------------------------------
> +                               MISC
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_NUM_WRITEBUFFER_ENTRIES  4       /* size of write buffer */
> +#define XCHAL_INST_FETCH_WIDTH         4       /* instr-fetch width in bytes */
> +#define XCHAL_DATA_WIDTH               4       /* data width in bytes */
> +/*  In T1050, applies to selected core load and store instructions (see ISA): */
> +#define XCHAL_UNALIGNED_LOAD_EXCEPTION 1       /* unaligned loads cause exc. */
> +#define XCHAL_UNALIGNED_STORE_EXCEPTION        1       /* unaligned stores cause exc.*/
> +
> +#define XCHAL_SW_VERSION               800002  /* sw version of this header */
> +
> +#define XCHAL_CORE_ID                  "fsf"   /* alphanum core name
> +                                                  (CoreID) set in the Xtensa
> +                                                  Processor Generator */
> +
> +#define XCHAL_CORE_DESCRIPTION         "fsf standard core"
> +#define XCHAL_BUILD_UNIQUE_ID          0x00006700      /* 22-bit sw build ID */
> +
> +/*
> + *  These definitions describe the hardware targeted by this software.
> + */
> +#define XCHAL_HW_CONFIGID0             0xC103C3FF      /* ConfigID hi 32 bits*/
> +#define XCHAL_HW_CONFIGID1             0x0C006700      /* ConfigID lo 32 bits*/
> +#define XCHAL_HW_VERSION_NAME          "LX2.0.0"       /* full version name */
> +#define XCHAL_HW_VERSION_MAJOR         2200    /* major ver# of targeted hw */
> +#define XCHAL_HW_VERSION_MINOR         0       /* minor ver# of targeted hw */
> +#define XTHAL_HW_REL_LX2               1
> +#define XTHAL_HW_REL_LX2_0             1
> +#define XTHAL_HW_REL_LX2_0_0           1
> +#define XCHAL_HW_CONFIGID_RELIABLE     1
> +/*  If software targets a *range* of hardware versions, these are the bounds: */
> +#define XCHAL_HW_MIN_VERSION_MAJOR     2200    /* major v of earliest tgt hw */
> +#define XCHAL_HW_MIN_VERSION_MINOR     0       /* minor v of earliest tgt hw */
> +#define XCHAL_HW_MAX_VERSION_MAJOR     2200    /* major v of latest tgt hw */
> +#define XCHAL_HW_MAX_VERSION_MINOR     0       /* minor v of latest tgt hw */
> +
> +
> +/*----------------------------------------------------------------------
> +                               CACHE
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_ICACHE_LINESIZE          16      /* I-cache line size in bytes */
> +#define XCHAL_DCACHE_LINESIZE          16      /* D-cache line size in bytes */
> +#define XCHAL_ICACHE_LINEWIDTH         4       /* log2(I line size in bytes) */
> +#define XCHAL_DCACHE_LINEWIDTH         4       /* log2(D line size in bytes) */
> +
> +#define XCHAL_ICACHE_SIZE              8192    /* I-cache size in bytes or 0 */
> +#define XCHAL_DCACHE_SIZE              8192    /* D-cache size in bytes or 0 */
> +
> +#define XCHAL_DCACHE_IS_WRITEBACK      0       /* writeback feature */
> +
> +
> +
> +
> +/****************************************************************************
> +    Parameters Useful for PRIVILEGED (Supervisory or Non-Virtualized) Code
> + ****************************************************************************/
> +
> +
> +#ifndef XTENSA_HAL_NON_PRIVILEGED_ONLY
> +
> +/*----------------------------------------------------------------------
> +                               CACHE
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_HAVE_PIF                 1       /* any outbound PIF present */
> +
> +/*  If present, cache size in bytes == (ways * 2^(linewidth + setwidth)).  */
> +
> +/*  Number of cache sets in log2(lines per way):  */
> +#define XCHAL_ICACHE_SETWIDTH          8
> +#define XCHAL_DCACHE_SETWIDTH          8
> +
> +/*  Cache set associativity (number of ways):  */
> +#define XCHAL_ICACHE_WAYS              2
> +#define XCHAL_DCACHE_WAYS              2
> +
> +/*  Cache features:  */
> +#define XCHAL_ICACHE_LINE_LOCKABLE     0
> +#define XCHAL_DCACHE_LINE_LOCKABLE     0
> +#define XCHAL_ICACHE_ECC_PARITY                0
> +#define XCHAL_DCACHE_ECC_PARITY                0
> +
> +/*  Number of encoded cache attr bits (see <xtensa/hal.h> for decoded bits):  */
> +#define XCHAL_CA_BITS                  4
> +
> +
> +/*----------------------------------------------------------------------
> +                       INTERNAL I/D RAM/ROMs and XLMI
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_NUM_INSTROM              0       /* number of core instr. ROMs */
> +#define XCHAL_NUM_INSTRAM              0       /* number of core instr. RAMs */
> +#define XCHAL_NUM_DATAROM              0       /* number of core data ROMs */
> +#define XCHAL_NUM_DATARAM              0       /* number of core data RAMs */
> +#define XCHAL_NUM_URAM                 0       /* number of core unified RAMs*/
> +#define XCHAL_NUM_XLMI                 0       /* number of core XLMI ports */
> +
> +
> +/*----------------------------------------------------------------------
> +                       INTERRUPTS and TIMERS
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_HAVE_INTERRUPTS          1       /* interrupt option */
> +#define XCHAL_HAVE_HIGHPRI_INTERRUPTS  1       /* med/high-pri. interrupts */
> +#define XCHAL_HAVE_NMI                 0       /* non-maskable interrupt */
> +#define XCHAL_HAVE_CCOUNT              1       /* CCOUNT reg. (timer option) */
> +#define XCHAL_NUM_TIMERS               3       /* number of CCOMPAREn regs */
> +#define XCHAL_NUM_INTERRUPTS           17      /* number of interrupts */
> +#define XCHAL_NUM_INTERRUPTS_LOG2      5       /* ceil(log2(NUM_INTERRUPTS)) */
> +#define XCHAL_NUM_EXTINTERRUPTS                10      /* num of external interrupts */
> +#define XCHAL_NUM_INTLEVELS            4       /* number of interrupt levels
> +                                                  (not including level zero) */
> +#define XCHAL_EXCM_LEVEL               1       /* level masked by PS.EXCM */
> +       /* (always 1 in XEA1; levels 2 .. EXCM_LEVEL are "medium priority") */
> +
> +/*  Masks of interrupts at each interrupt level:  */
> +#define XCHAL_INTLEVEL1_MASK           0x000064F9
> +#define XCHAL_INTLEVEL2_MASK           0x00008902
> +#define XCHAL_INTLEVEL3_MASK           0x00011204
> +#define XCHAL_INTLEVEL4_MASK           0x00000000
> +#define XCHAL_INTLEVEL5_MASK           0x00000000
> +#define XCHAL_INTLEVEL6_MASK           0x00000000
> +#define XCHAL_INTLEVEL7_MASK           0x00000000
> +
> +/*  Masks of interrupts at each range 1..n of interrupt levels:  */
> +#define XCHAL_INTLEVEL1_ANDBELOW_MASK  0x000064F9
> +#define XCHAL_INTLEVEL2_ANDBELOW_MASK  0x0000EDFB
> +#define XCHAL_INTLEVEL3_ANDBELOW_MASK  0x0001FFFF
> +#define XCHAL_INTLEVEL4_ANDBELOW_MASK  0x0001FFFF
> +#define XCHAL_INTLEVEL5_ANDBELOW_MASK  0x0001FFFF
> +#define XCHAL_INTLEVEL6_ANDBELOW_MASK  0x0001FFFF
> +#define XCHAL_INTLEVEL7_ANDBELOW_MASK  0x0001FFFF
> +
> +/*  Level of each interrupt:  */
> +#define XCHAL_INT0_LEVEL               1
> +#define XCHAL_INT1_LEVEL               2
> +#define XCHAL_INT2_LEVEL               3
> +#define XCHAL_INT3_LEVEL               1
> +#define XCHAL_INT4_LEVEL               1
> +#define XCHAL_INT5_LEVEL               1
> +#define XCHAL_INT6_LEVEL               1
> +#define XCHAL_INT7_LEVEL               1
> +#define XCHAL_INT8_LEVEL               2
> +#define XCHAL_INT9_LEVEL               3
> +#define XCHAL_INT10_LEVEL              1
> +#define XCHAL_INT11_LEVEL              2
> +#define XCHAL_INT12_LEVEL              3
> +#define XCHAL_INT13_LEVEL              1
> +#define XCHAL_INT14_LEVEL              1
> +#define XCHAL_INT15_LEVEL              2
> +#define XCHAL_INT16_LEVEL              3
> +#define XCHAL_DEBUGLEVEL               4       /* debug interrupt level */
> +#define XCHAL_HAVE_DEBUG_EXTERN_INT    0       /* OCD external db interrupt */
> +
> +/*  Type of each interrupt:  */
> +#define XCHAL_INT0_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT1_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT2_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT3_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT4_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT5_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT6_TYPE        XTHAL_INTTYPE_EXTERN_LEVEL
> +#define XCHAL_INT7_TYPE        XTHAL_INTTYPE_EXTERN_EDGE
> +#define XCHAL_INT8_TYPE        XTHAL_INTTYPE_EXTERN_EDGE
> +#define XCHAL_INT9_TYPE        XTHAL_INTTYPE_EXTERN_EDGE
> +#define XCHAL_INT10_TYPE       XTHAL_INTTYPE_TIMER
> +#define XCHAL_INT11_TYPE       XTHAL_INTTYPE_TIMER
> +#define XCHAL_INT12_TYPE       XTHAL_INTTYPE_TIMER
> +#define XCHAL_INT13_TYPE       XTHAL_INTTYPE_SOFTWARE
> +#define XCHAL_INT14_TYPE       XTHAL_INTTYPE_SOFTWARE
> +#define XCHAL_INT15_TYPE       XTHAL_INTTYPE_SOFTWARE
> +#define XCHAL_INT16_TYPE       XTHAL_INTTYPE_SOFTWARE
> +
> +/*  Masks of interrupts for each type of interrupt:  */
> +#define XCHAL_INTTYPE_MASK_UNCONFIGURED        0xFFFE0000
> +#define XCHAL_INTTYPE_MASK_SOFTWARE    0x0001E000
> +#define XCHAL_INTTYPE_MASK_EXTERN_EDGE 0x00000380
> +#define XCHAL_INTTYPE_MASK_EXTERN_LEVEL        0x0000007F
> +#define XCHAL_INTTYPE_MASK_TIMER       0x00001C00
> +#define XCHAL_INTTYPE_MASK_NMI         0x00000000
> +#define XCHAL_INTTYPE_MASK_WRITE_ERROR 0x00000000
> +
> +/*  Interrupt numbers assigned to specific interrupt sources:  */
> +#define XCHAL_TIMER0_INTERRUPT         10      /* CCOMPARE0 */
> +#define XCHAL_TIMER1_INTERRUPT         11      /* CCOMPARE1 */
> +#define XCHAL_TIMER2_INTERRUPT         12      /* CCOMPARE2 */
> +#define XCHAL_TIMER3_INTERRUPT         XTHAL_TIMER_UNCONFIGURED
> +
> +/*  Interrupt numbers for levels at which only one interrupt is configured:  */
> +/*  (There are many interrupts each at level(s) 1, 2, 3.)  */
> +
> +
> +/*
> + *  External interrupt vectors/levels.
> + *  These macros describe how Xtensa processor interrupt numbers
> + *  (as numbered internally, eg. in INTERRUPT and INTENABLE registers)
> + *  map to external BInterrupt<n> pins, for those interrupts
> + *  configured as external (level-triggered, edge-triggered, or NMI).
> + *  See the Xtensa processor databook for more details.
> + */
> +
> +/*  Core interrupt numbers mapped to each EXTERNAL interrupt number:  */
> +#define XCHAL_EXTINT0_NUM              0       /* (intlevel 1) */
> +#define XCHAL_EXTINT1_NUM              1       /* (intlevel 2) */
> +#define XCHAL_EXTINT2_NUM              2       /* (intlevel 3) */
> +#define XCHAL_EXTINT3_NUM              3       /* (intlevel 1) */
> +#define XCHAL_EXTINT4_NUM              4       /* (intlevel 1) */
> +#define XCHAL_EXTINT5_NUM              5       /* (intlevel 1) */
> +#define XCHAL_EXTINT6_NUM              6       /* (intlevel 1) */
> +#define XCHAL_EXTINT7_NUM              7       /* (intlevel 1) */
> +#define XCHAL_EXTINT8_NUM              8       /* (intlevel 2) */
> +#define XCHAL_EXTINT9_NUM              9       /* (intlevel 3) */
> +
> +
> +/*----------------------------------------------------------------------
> +                       EXCEPTIONS and VECTORS
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_XEA_VERSION              2       /* Xtensa Exception Architecture
> +                                                  number: 1 == XEA1 (old)
> +                                                          2 == XEA2 (new)
> +                                                          0 == XEAX (extern) */
> +#define XCHAL_HAVE_XEA1                        0       /* Exception Architecture 1 */
> +#define XCHAL_HAVE_XEA2                        1       /* Exception Architecture 2 */
> +#define XCHAL_HAVE_XEAX                        0       /* External Exception Arch. */
> +#define XCHAL_HAVE_EXCEPTIONS          1       /* exception option */
> +#define XCHAL_HAVE_MEM_ECC_PARITY      0       /* local memory ECC/parity */
> +
> +#define XCHAL_RESET_VECTOR_VADDR       0xFE000020
> +#define XCHAL_RESET_VECTOR_PADDR       0xFE000020
> +#define XCHAL_USER_VECTOR_VADDR                0xD0000220
> +#define XCHAL_USER_VECTOR_PADDR                0x00000220
> +#define XCHAL_KERNEL_VECTOR_VADDR      0xD0000200
> +#define XCHAL_KERNEL_VECTOR_PADDR      0x00000200
> +#define XCHAL_DOUBLEEXC_VECTOR_VADDR   0xD0000290
> +#define XCHAL_DOUBLEEXC_VECTOR_PADDR   0x00000290
> +#define XCHAL_WINDOW_VECTORS_VADDR     0xD0000000
> +#define XCHAL_WINDOW_VECTORS_PADDR     0x00000000
> +#define XCHAL_INTLEVEL2_VECTOR_VADDR   0xD0000240
> +#define XCHAL_INTLEVEL2_VECTOR_PADDR   0x00000240
> +#define XCHAL_INTLEVEL3_VECTOR_VADDR   0xD0000250
> +#define XCHAL_INTLEVEL3_VECTOR_PADDR   0x00000250
> +#define XCHAL_INTLEVEL4_VECTOR_VADDR   0xFE000520
> +#define XCHAL_INTLEVEL4_VECTOR_PADDR   0xFE000520
> +#define XCHAL_DEBUG_VECTOR_VADDR       XCHAL_INTLEVEL4_VECTOR_VADDR
> +#define XCHAL_DEBUG_VECTOR_PADDR       XCHAL_INTLEVEL4_VECTOR_PADDR
> +
> +
> +/*----------------------------------------------------------------------
> +                               DEBUG
> +  ----------------------------------------------------------------------*/
> +
> +#define XCHAL_HAVE_OCD                 1       /* OnChipDebug option */
> +#define XCHAL_NUM_IBREAK               2       /* number of IBREAKn regs */
> +#define XCHAL_NUM_DBREAK               2       /* number of DBREAKn regs */
> +#define XCHAL_HAVE_OCD_DIR_ARRAY       1       /* faster OCD option */
> +
> +
> +/*----------------------------------------------------------------------
> +                               MMU
> +  ----------------------------------------------------------------------*/
> +
> +/*  See <xtensa/config/core-matmap.h> header file for more details.  */
> +
> +#define XCHAL_HAVE_TLBS                        1       /* inverse of HAVE_CACHEATTR */
> +#define XCHAL_HAVE_SPANNING_WAY                0       /* one way maps I+D 4GB vaddr */
> +#define XCHAL_HAVE_IDENTITY_MAP                0       /* vaddr == paddr always */
> +#define XCHAL_HAVE_CACHEATTR           0       /* CACHEATTR register present */
> +#define XCHAL_HAVE_MIMIC_CACHEATTR     0       /* region protection */
> +#define XCHAL_HAVE_XLT_CACHEATTR       0       /* region prot. w/translation */
> +#define XCHAL_HAVE_PTP_MMU             1       /* full MMU (with page table
> +                                                  [autorefill] and protection)
> +                                                  usable for an MMU-based OS */
> +/*  If none of the above last 4 are set, it's a custom TLB configuration.  */
> +#define XCHAL_ITLB_ARF_ENTRIES_LOG2    2       /* log2(autorefill way size) */
> +#define XCHAL_DTLB_ARF_ENTRIES_LOG2    2       /* log2(autorefill way size) */
> +
> +#define XCHAL_MMU_ASID_BITS            8       /* number of bits in ASIDs */
> +#define XCHAL_MMU_RINGS                        4       /* number of rings (1..4) */
> +#define XCHAL_MMU_RING_BITS            2       /* num of bits in RING field */
> +
> +#endif /* !XTENSA_HAL_NON_PRIVILEGED_ONLY */
> +
> +
> +#endif /* _XTENSA_CORE_CONFIGURATION_H */
> +
> diff --git a/target-xtensa/core-fsf/gdb-config.c b/target-xtensa/core-fsf/gdb-config.c
> new file mode 100644
> index 0000000..6705d9c
> --- /dev/null
> +++ b/target-xtensa/core-fsf/gdb-config.c
> @@ -0,0 +1,152 @@
> +/* Configuration for the Xtensa architecture for GDB, the GNU debugger.
> +
> +   Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
> +
> +   This file is part of GDB.
> +
> +   This program is free software; you can redistribute it and/or modify
> +   it under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or

Nack. GPLv3 is by design incompatible with GPLv2only (but not with
GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
before v3 switch.

As a side note, a quick grep shows that GPLv2only is a small minority
in QEMU. In theory it should be possible to agree to switch from
GPLv2only to some GPLv3 compatible license for all of QEMU code, or in
a theory with alternative universes, even get FSF to relicense GDB
under GPLv2only compatible way. Or, with the aid of infinite number of
monkeys of Internet waiting to waste their time, rewrite incompatible
but interesting parts of GDB or QEMU under The One True License of the
day.

> +   (at your option) any later version.
> +
> +   This program is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
> +
> +  /*    idx ofs bi sz al targno  flags cp typ group name  */
> +
> +  XTREG(  0,  0,32, 4, 4,0x0020,0x0006,-2, 9,0x0100,pc,          0,0,0,0,0,0)
> +  XTREG(  1,  4,32, 4, 4,0x0100,0x0006,-2, 1,0x0002,ar0,         0,0,0,0,0,0)
> +  XTREG(  2,  8,32, 4, 4,0x0101,0x0006,-2, 1,0x0002,ar1,         0,0,0,0,0,0)
> +  XTREG(  3, 12,32, 4, 4,0x0102,0x0006,-2, 1,0x0002,ar2,         0,0,0,0,0,0)
> +  XTREG(  4, 16,32, 4, 4,0x0103,0x0006,-2, 1,0x0002,ar3,         0,0,0,0,0,0)
> +  XTREG(  5, 20,32, 4, 4,0x0104,0x0006,-2, 1,0x0002,ar4,         0,0,0,0,0,0)
> +  XTREG(  6, 24,32, 4, 4,0x0105,0x0006,-2, 1,0x0002,ar5,         0,0,0,0,0,0)
> +  XTREG(  7, 28,32, 4, 4,0x0106,0x0006,-2, 1,0x0002,ar6,         0,0,0,0,0,0)
> +  XTREG(  8, 32,32, 4, 4,0x0107,0x0006,-2, 1,0x0002,ar7,         0,0,0,0,0,0)
> +  XTREG(  9, 36,32, 4, 4,0x0108,0x0006,-2, 1,0x0002,ar8,         0,0,0,0,0,0)
> +  XTREG( 10, 40,32, 4, 4,0x0109,0x0006,-2, 1,0x0002,ar9,         0,0,0,0,0,0)
> +  XTREG( 11, 44,32, 4, 4,0x010a,0x0006,-2, 1,0x0002,ar10,        0,0,0,0,0,0)
> +  XTREG( 12, 48,32, 4, 4,0x010b,0x0006,-2, 1,0x0002,ar11,        0,0,0,0,0,0)
> +  XTREG( 13, 52,32, 4, 4,0x010c,0x0006,-2, 1,0x0002,ar12,        0,0,0,0,0,0)
> +  XTREG( 14, 56,32, 4, 4,0x010d,0x0006,-2, 1,0x0002,ar13,        0,0,0,0,0,0)
> +  XTREG( 15, 60,32, 4, 4,0x010e,0x0006,-2, 1,0x0002,ar14,        0,0,0,0,0,0)
> +  XTREG( 16, 64,32, 4, 4,0x010f,0x0006,-2, 1,0x0002,ar15,        0,0,0,0,0,0)
> +  XTREG( 17, 68,32, 4, 4,0x0110,0x0006,-2, 1,0x0002,ar16,        0,0,0,0,0,0)
> +  XTREG( 18, 72,32, 4, 4,0x0111,0x0006,-2, 1,0x0002,ar17,        0,0,0,0,0,0)
> +  XTREG( 19, 76,32, 4, 4,0x0112,0x0006,-2, 1,0x0002,ar18,        0,0,0,0,0,0)
> +  XTREG( 20, 80,32, 4, 4,0x0113,0x0006,-2, 1,0x0002,ar19,        0,0,0,0,0,0)
> +  XTREG( 21, 84,32, 4, 4,0x0114,0x0006,-2, 1,0x0002,ar20,        0,0,0,0,0,0)
> +  XTREG( 22, 88,32, 4, 4,0x0115,0x0006,-2, 1,0x0002,ar21,        0,0,0,0,0,0)
> +  XTREG( 23, 92,32, 4, 4,0x0116,0x0006,-2, 1,0x0002,ar22,        0,0,0,0,0,0)
> +  XTREG( 24, 96,32, 4, 4,0x0117,0x0006,-2, 1,0x0002,ar23,        0,0,0,0,0,0)
> +  XTREG( 25,100,32, 4, 4,0x0118,0x0006,-2, 1,0x0002,ar24,        0,0,0,0,0,0)
> +  XTREG( 26,104,32, 4, 4,0x0119,0x0006,-2, 1,0x0002,ar25,        0,0,0,0,0,0)
> +  XTREG( 27,108,32, 4, 4,0x011a,0x0006,-2, 1,0x0002,ar26,        0,0,0,0,0,0)
> +  XTREG( 28,112,32, 4, 4,0x011b,0x0006,-2, 1,0x0002,ar27,        0,0,0,0,0,0)
> +  XTREG( 29,116,32, 4, 4,0x011c,0x0006,-2, 1,0x0002,ar28,        0,0,0,0,0,0)
> +  XTREG( 30,120,32, 4, 4,0x011d,0x0006,-2, 1,0x0002,ar29,        0,0,0,0,0,0)
> +  XTREG( 31,124,32, 4, 4,0x011e,0x0006,-2, 1,0x0002,ar30,        0,0,0,0,0,0)
> +  XTREG( 32,128,32, 4, 4,0x011f,0x0006,-2, 1,0x0002,ar31,        0,0,0,0,0,0)
> +  XTREG( 33,132,32, 4, 4,0x0120,0x0006,-2, 1,0x0002,ar32,        0,0,0,0,0,0)
> +  XTREG( 34,136,32, 4, 4,0x0121,0x0006,-2, 1,0x0002,ar33,        0,0,0,0,0,0)
> +  XTREG( 35,140,32, 4, 4,0x0122,0x0006,-2, 1,0x0002,ar34,        0,0,0,0,0,0)
> +  XTREG( 36,144,32, 4, 4,0x0123,0x0006,-2, 1,0x0002,ar35,        0,0,0,0,0,0)
> +  XTREG( 37,148,32, 4, 4,0x0124,0x0006,-2, 1,0x0002,ar36,        0,0,0,0,0,0)
> +  XTREG( 38,152,32, 4, 4,0x0125,0x0006,-2, 1,0x0002,ar37,        0,0,0,0,0,0)
> +  XTREG( 39,156,32, 4, 4,0x0126,0x0006,-2, 1,0x0002,ar38,        0,0,0,0,0,0)
> +  XTREG( 40,160,32, 4, 4,0x0127,0x0006,-2, 1,0x0002,ar39,        0,0,0,0,0,0)
> +  XTREG( 41,164,32, 4, 4,0x0128,0x0006,-2, 1,0x0002,ar40,        0,0,0,0,0,0)
> +  XTREG( 42,168,32, 4, 4,0x0129,0x0006,-2, 1,0x0002,ar41,        0,0,0,0,0,0)
> +  XTREG( 43,172,32, 4, 4,0x012a,0x0006,-2, 1,0x0002,ar42,        0,0,0,0,0,0)
> +  XTREG( 44,176,32, 4, 4,0x012b,0x0006,-2, 1,0x0002,ar43,        0,0,0,0,0,0)
> +  XTREG( 45,180,32, 4, 4,0x012c,0x0006,-2, 1,0x0002,ar44,        0,0,0,0,0,0)
> +  XTREG( 46,184,32, 4, 4,0x012d,0x0006,-2, 1,0x0002,ar45,        0,0,0,0,0,0)
> +  XTREG( 47,188,32, 4, 4,0x012e,0x0006,-2, 1,0x0002,ar46,        0,0,0,0,0,0)
> +  XTREG( 48,192,32, 4, 4,0x012f,0x0006,-2, 1,0x0002,ar47,        0,0,0,0,0,0)
> +  XTREG( 49,196,32, 4, 4,0x0130,0x0006,-2, 1,0x0002,ar48,        0,0,0,0,0,0)
> +  XTREG( 50,200,32, 4, 4,0x0131,0x0006,-2, 1,0x0002,ar49,        0,0,0,0,0,0)
> +  XTREG( 51,204,32, 4, 4,0x0132,0x0006,-2, 1,0x0002,ar50,        0,0,0,0,0,0)
> +  XTREG( 52,208,32, 4, 4,0x0133,0x0006,-2, 1,0x0002,ar51,        0,0,0,0,0,0)
> +  XTREG( 53,212,32, 4, 4,0x0134,0x0006,-2, 1,0x0002,ar52,        0,0,0,0,0,0)
> +  XTREG( 54,216,32, 4, 4,0x0135,0x0006,-2, 1,0x0002,ar53,        0,0,0,0,0,0)
> +  XTREG( 55,220,32, 4, 4,0x0136,0x0006,-2, 1,0x0002,ar54,        0,0,0,0,0,0)
> +  XTREG( 56,224,32, 4, 4,0x0137,0x0006,-2, 1,0x0002,ar55,        0,0,0,0,0,0)
> +  XTREG( 57,228,32, 4, 4,0x0138,0x0006,-2, 1,0x0002,ar56,        0,0,0,0,0,0)
> +  XTREG( 58,232,32, 4, 4,0x0139,0x0006,-2, 1,0x0002,ar57,        0,0,0,0,0,0)
> +  XTREG( 59,236,32, 4, 4,0x013a,0x0006,-2, 1,0x0002,ar58,        0,0,0,0,0,0)
> +  XTREG( 60,240,32, 4, 4,0x013b,0x0006,-2, 1,0x0002,ar59,        0,0,0,0,0,0)
> +  XTREG( 61,244,32, 4, 4,0x013c,0x0006,-2, 1,0x0002,ar60,        0,0,0,0,0,0)
> +  XTREG( 62,248,32, 4, 4,0x013d,0x0006,-2, 1,0x0002,ar61,        0,0,0,0,0,0)
> +  XTREG( 63,252,32, 4, 4,0x013e,0x0006,-2, 1,0x0002,ar62,        0,0,0,0,0,0)
> +  XTREG( 64,256,32, 4, 4,0x013f,0x0006,-2, 1,0x0002,ar63,        0,0,0,0,0,0)
> +  XTREG( 65,260,32, 4, 4,0x0200,0x0006,-2, 2,0x1100,lbeg,        0,0,0,0,0,0)
> +  XTREG( 66,264,32, 4, 4,0x0201,0x0006,-2, 2,0x1100,lend,        0,0,0,0,0,0)
> +  XTREG( 67,268,32, 4, 4,0x0202,0x0006,-2, 2,0x1100,lcount,      0,0,0,0,0,0)
> +  XTREG( 68,272, 6, 4, 4,0x0203,0x0006,-2, 2,0x1100,sar,         0,0,0,0,0,0)
> +  XTREG( 69,276,32, 4, 4,0x0205,0x0006,-2, 2,0x1100,litbase,     0,0,0,0,0,0)
> +  XTREG( 70,280, 4, 4, 4,0x0248,0x0006,-2, 2,0x1002,windowbase,  0,0,0,0,0,0)
> +  XTREG( 71,284,16, 4, 4,0x0249,0x0006,-2, 2,0x1002,windowstart, 0,0,0,0,0,0)
> +  XTREG( 72,288,32, 4, 4,0x02b0,0x0002,-2, 2,0x1000,sr176,       0,0,0,0,0,0)
> +  XTREG( 73,292,32, 4, 4,0x02d0,0x0002,-2, 2,0x1000,sr208,       0,0,0,0,0,0)
> +  XTREG( 74,296,19, 4, 4,0x02e6,0x0006,-2, 2,0x1100,ps,          0,0,0,0,0,0)
> +  XTREG( 75,300,32, 4, 4,0x0253,0x0007,-2, 2,0x1000,ptevaddr,    0,0,0,0,0,0)
> +  XTREG( 76,304,32, 4, 4,0x025a,0x0007,-2, 2,0x1000,rasid,       0,0,0,0,0,0)
> +  XTREG( 77,308,18, 4, 4,0x025b,0x0007,-2, 2,0x1000,itlbcfg,     0,0,0,0,0,0)
> +  XTREG( 78,312,18, 4, 4,0x025c,0x0007,-2, 2,0x1000,dtlbcfg,     0,0,0,0,0,0)
> +  XTREG( 79,316, 2, 4, 4,0x0260,0x0007,-2, 2,0x1000,ibreakenable,0,0,0,0,0,0)
> +  XTREG( 80,320,32, 4, 4,0x0268,0x0007,-2, 2,0x1000,ddr,         0,0,0,0,0,0)
> +  XTREG( 81,324,32, 4, 4,0x0280,0x0007,-2, 2,0x1000,ibreaka0,    0,0,0,0,0,0)
> +  XTREG( 82,328,32, 4, 4,0x0281,0x0007,-2, 2,0x1000,ibreaka1,    0,0,0,0,0,0)
> +  XTREG( 83,332,32, 4, 4,0x0290,0x0007,-2, 2,0x1000,dbreaka0,    0,0,0,0,0,0)
> +  XTREG( 84,336,32, 4, 4,0x0291,0x0007,-2, 2,0x1000,dbreaka1,    0,0,0,0,0,0)
> +  XTREG( 85,340,32, 4, 4,0x02a0,0x0007,-2, 2,0x1000,dbreakc0,    0,0,0,0,0,0)
> +  XTREG( 86,344,32, 4, 4,0x02a1,0x0007,-2, 2,0x1000,dbreakc1,    0,0,0,0,0,0)
> +  XTREG( 87,348,32, 4, 4,0x02b1,0x0007,-2, 2,0x1000,epc1,        0,0,0,0,0,0)
> +  XTREG( 88,352,32, 4, 4,0x02b2,0x0007,-2, 2,0x1000,epc2,        0,0,0,0,0,0)
> +  XTREG( 89,356,32, 4, 4,0x02b3,0x0007,-2, 2,0x1000,epc3,        0,0,0,0,0,0)
> +  XTREG( 90,360,32, 4, 4,0x02b4,0x0007,-2, 2,0x1000,epc4,        0,0,0,0,0,0)
> +  XTREG( 91,364,32, 4, 4,0x02c0,0x0007,-2, 2,0x1000,depc,        0,0,0,0,0,0)
> +  XTREG( 92,368,19, 4, 4,0x02c2,0x0007,-2, 2,0x1000,eps2,        0,0,0,0,0,0)
> +  XTREG( 93,372,19, 4, 4,0x02c3,0x0007,-2, 2,0x1000,eps3,        0,0,0,0,0,0)
> +  XTREG( 94,376,19, 4, 4,0x02c4,0x0007,-2, 2,0x1000,eps4,        0,0,0,0,0,0)
> +  XTREG( 95,380,32, 4, 4,0x02d1,0x0007,-2, 2,0x1000,excsave1,    0,0,0,0,0,0)
> +  XTREG( 96,384,32, 4, 4,0x02d2,0x0007,-2, 2,0x1000,excsave2,    0,0,0,0,0,0)
> +  XTREG( 97,388,32, 4, 4,0x02d3,0x0007,-2, 2,0x1000,excsave3,    0,0,0,0,0,0)
> +  XTREG( 98,392,32, 4, 4,0x02d4,0x0007,-2, 2,0x1000,excsave4,    0,0,0,0,0,0)
> +  XTREG( 99,396,17, 4, 4,0x02e2,0x000b,-2, 2,0x1000,interrupt,   0,0,0,0,0,0)
> +  XTREG(100,400,17, 4, 4,0x02e2,0x000d,-2, 2,0x1000,intset,      0,0,0,0,0,0)
> +  XTREG(101,404,17, 4, 4,0x02e3,0x000d,-2, 2,0x1000,intclear,    0,0,0,0,0,0)
> +  XTREG(102,408,17, 4, 4,0x02e4,0x0007,-2, 2,0x1000,intenable,   0,0,0,0,0,0)
> +  XTREG(103,412, 6, 4, 4,0x02e8,0x0007,-2, 2,0x1000,exccause,    0,0,0,0,0,0)
> +  XTREG(104,416,12, 4, 4,0x02e9,0x0003,-2, 2,0x1000,debugcause,  0,0,0,0,0,0)
> +  XTREG(105,420,32, 4, 4,0x02ea,0x000f,-2, 2,0x1000,ccount,      0,0,0,0,0,0)
> +  XTREG(106,424,32, 4, 4,0x02eb,0x0003,-2, 2,0x1000,prid,        0,0,0,0,0,0)
> +  XTREG(107,428,32, 4, 4,0x02ec,0x000f,-2, 2,0x1000,icount,      0,0,0,0,0,0)
> +  XTREG(108,432, 4, 4, 4,0x02ed,0x0007,-2, 2,0x1000,icountlevel, 0,0,0,0,0,0)
> +  XTREG(109,436,32, 4, 4,0x02ee,0x0007,-2, 2,0x1000,excvaddr,    0,0,0,0,0,0)
> +  XTREG(110,440,32, 4, 4,0x02f0,0x000f,-2, 2,0x1000,ccompare0,   0,0,0,0,0,0)
> +  XTREG(111,444,32, 4, 4,0x02f1,0x000f,-2, 2,0x1000,ccompare1,   0,0,0,0,0,0)
> +  XTREG(112,448,32, 4, 4,0x02f2,0x000f,-2, 2,0x1000,ccompare2,   0,0,0,0,0,0)
> +  XTREG(113,452,32, 4, 4,0x02f4,0x0007,-2, 2,0x1000,misc0,       0,0,0,0,0,0)
> +  XTREG(114,456,32, 4, 4,0x02f5,0x0007,-2, 2,0x1000,misc1,       0,0,0,0,0,0)
> +  XTREG(115,460,32, 4, 4,0x0000,0x0006,-2, 8,0x0100,a0,          0,0,0,0,0,0)
> +  XTREG(116,464,32, 4, 4,0x0001,0x0006,-2, 8,0x0100,a1,          0,0,0,0,0,0)
> +  XTREG(117,468,32, 4, 4,0x0002,0x0006,-2, 8,0x0100,a2,          0,0,0,0,0,0)
> +  XTREG(118,472,32, 4, 4,0x0003,0x0006,-2, 8,0x0100,a3,          0,0,0,0,0,0)
> +  XTREG(119,476,32, 4, 4,0x0004,0x0006,-2, 8,0x0100,a4,          0,0,0,0,0,0)
> +  XTREG(120,480,32, 4, 4,0x0005,0x0006,-2, 8,0x0100,a5,          0,0,0,0,0,0)
> +  XTREG(121,484,32, 4, 4,0x0006,0x0006,-2, 8,0x0100,a6,          0,0,0,0,0,0)
> +  XTREG(122,488,32, 4, 4,0x0007,0x0006,-2, 8,0x0100,a7,          0,0,0,0,0,0)
> +  XTREG(123,492,32, 4, 4,0x0008,0x0006,-2, 8,0x0100,a8,          0,0,0,0,0,0)
> +  XTREG(124,496,32, 4, 4,0x0009,0x0006,-2, 8,0x0100,a9,          0,0,0,0,0,0)
> +  XTREG(125,500,32, 4, 4,0x000a,0x0006,-2, 8,0x0100,a10,         0,0,0,0,0,0)
> +  XTREG(126,504,32, 4, 4,0x000b,0x0006,-2, 8,0x0100,a11,         0,0,0,0,0,0)
> +  XTREG(127,508,32, 4, 4,0x000c,0x0006,-2, 8,0x0100,a12,         0,0,0,0,0,0)
> +  XTREG(128,512,32, 4, 4,0x000d,0x0006,-2, 8,0x0100,a13,         0,0,0,0,0,0)
> +  XTREG(129,516,32, 4, 4,0x000e,0x0006,-2, 8,0x0100,a14,         0,0,0,0,0,0)
> +  XTREG(130,520,32, 4, 4,0x000f,0x0006,-2, 8,0x0100,a15,         0,0,0,0,0,0)
> --
> 1.7.6.4
>
>
>

Max Filippov Oct. 15, 2011, 1:15 p.m. UTC | #2

> > diff --git a/target-xtensa/core-fsf/gdb-config.c b/target-xtensa/core-fsf/gdb-config.c
> > new file mode 100644
> > index 0000000..6705d9c
> > --- /dev/null
> > +++ b/target-xtensa/core-fsf/gdb-config.c
> > @@ -0,0 +1,152 @@
> > +/* Configuration for the Xtensa architecture for GDB, the GNU debugger.
> > +
> > +   Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
> > +
> > +   This file is part of GDB.
> > +
> > +   This program is free software; you can redistribute it and/or modify
> > +   it under the terms of the GNU General Public License as published by
> > +   the Free Software Foundation; either version 3 of the License, or
> 
> Nack. GPLv3 is by design incompatible with GPLv2only (but not with
> GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
> before v3 switch.

Ok, let's drop this patch. Fortunately nothing really depends on it.
I could re-format xtensa-config.c from gdb-6.6, but register layout has changed since then.
 
Thanks.
-- Max

Max Filippov Oct. 15, 2011, 1:44 p.m. UTC | #3

> > Nack. GPLv3 is by design incompatible with GPLv2only (but not with
> > GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
> > before v3 switch.
> 
> Ok, let's drop this patch. Fortunately nothing really depends on it.
> I could re-format xtensa-config.c from gdb-6.6, but register layout has changed since then.
 
Or we can retain the core but disable gdb for it. If that's acceptable I will resend the patch.

Thanks.
-- Max

Blue Swirl Oct. 15, 2011, 1:50 p.m. UTC | #4

On Sat, Oct 15, 2011 at 1:44 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> > Nack. GPLv3 is by design incompatible with GPLv2only (but not with
>> > GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
>> > before v3 switch.
>>
>> Ok, let's drop this patch. Fortunately nothing really depends on it.
>> I could re-format xtensa-config.c from gdb-6.6, but register layout has changed since then.
>
> Or we can retain the core but disable gdb for it. If that's acceptable I will resend the patch.

Yes, it's possible to add GDB support later.

Andreas Färber Oct. 17, 2011, 10:45 a.m. UTC | #5

Am 15.10.2011 11:02, schrieb Blue Swirl:
> On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> diff --git a/target-xtensa/core-fsf/gdb-config.c b/target-xtensa/core-fsf/gdb-config.c
>> new file mode 100644
>> index 0000000..6705d9c
>> --- /dev/null
>> +++ b/target-xtensa/core-fsf/gdb-config.c
>> @@ -0,0 +1,152 @@
>> +/* Configuration for the Xtensa architecture for GDB, the GNU debugger.
>> +
>> +   Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
>> +
>> +   This file is part of GDB.
>> +
>> +   This program is free software; you can redistribute it and/or modify
>> +   it under the terms of the GNU General Public License as published by
>> +   the Free Software Foundation; either version 3 of the License, or
> 
> Nack. GPLv3 is by design incompatible with GPLv2only (but not with
> GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
> before v3 switch.
> 
> As a side note, a quick grep shows that GPLv2only is a small minority
> in QEMU. In theory it should be possible to agree to switch from
> GPLv2only to some GPLv3 compatible license for all of QEMU code, or in
> a theory with alternative universes, even get FSF to relicense GDB
> under GPLv2only compatible way. Or, with the aid of infinite number of
> monkeys of Internet waiting to waste their time, rewrite incompatible
> but interesting parts of GDB or QEMU under The One True License of the
> day.

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 of new
GPLv2-only code cooking and occasionally pouring in, especially from
qemu-kvm. Device assignment is a current example I encountered.

If we could make checkpatch.pl detect new GPLv2-only code, then I would
hope, given the dynamic QEMU development of the last few years, that the
GPLv2-only portions become so small (both in relation and absolute) that
they can either be replaced or the authors' permission be obtained to
change the license to GPLv2-or-later.

Andreas

Paolo Bonzini Oct. 17, 2011, 10:47 a.m. UTC | #6

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 of new
> GPLv2-only code cooking and occasionally pouring in, especially from
> qemu-kvm. Device assignment is a current example I encountered.
>
> If we could make checkpatch.pl detect new GPLv2-only code, then I would
> hope, given the dynamic QEMU development of the last few years, that the
> GPLv2-only portions become so small (both in relation and absolute) that
> they can either be replaced or the authors' permission be obtained to
> change the license to GPLv2-or-later.

That is close to impossible, you usually ask permission for all the 
authors in the history to avoid bigger problems.

Paolo

Andreas Färber Oct. 17, 2011, 11:07 a.m. UTC | #7

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 having old GPLv2-only code is one thing. But there's a lot of new
>> GPLv2-only code cooking and occasionally pouring in, especially from
>> qemu-kvm. Device assignment is a current example I encountered.
>>
>> If we could make checkpatch.pl detect new GPLv2-only code, then I would
>> hope, given the dynamic QEMU development of the last few years, that the
>> GPLv2-only portions become so small (both in relation and absolute) that
>> they can either be replaced or the authors' permission be obtained to
>> change the license to GPLv2-or-later.
> 
> 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.

I was thinking of how much code we rewrote for TCG, qdev, etc. In the
end it'll depend on which files are affected, and I don't have a list -
hard to grep due to varying formulations and line breaks.

Andreas

Paolo Bonzini Oct. 17, 2011, 11:10 a.m. UTC | #8

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 trust 
that) almost never disappear, no matter how much you rewrite.  Even 
dyngen->TCG kept a lot of the target-* code unchanged.

Making a list of GPLv2 files would be a start, though.

Paolo

Anthony Liguori Oct. 17, 2011, 12:38 p.m. UTC | #9

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<jcmvbkbc@gmail.com>  wrote:
>>> diff --git a/target-xtensa/core-fsf/gdb-config.c b/target-xtensa/core-fsf/gdb-config.c
>>> new file mode 100644
>>> index 0000000..6705d9c
>>> --- /dev/null
>>> +++ b/target-xtensa/core-fsf/gdb-config.c
>>> @@ -0,0 +1,152 @@
>>> +/* Configuration for the Xtensa architecture for GDB, the GNU debugger.
>>> +
>>> +   Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
>>> +
>>> +   This file is part of GDB.
>>> +
>>> +   This program is free software; you can redistribute it and/or modify
>>> +   it under the terms of the GNU General Public License as published by
>>> +   the Free Software Foundation; either version 3 of the License, or
>>
>> Nack. GPLv3 is by design incompatible with GPLv2only (but not with
>> GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB
>> before v3 switch.
>>
>> As a side note, a quick grep shows that GPLv2only is a small minority
>> in QEMU. In theory it should be possible to agree to switch from
>> GPLv2only to some GPLv3 compatible license for all of QEMU code, or in
>> a theory with alternative universes, even get FSF to relicense GDB
>> under GPLv2only compatible way. Or, with the aid of infinite number of
>> monkeys of Internet waiting to waste their time, rewrite incompatible
>> but interesting parts of GDB or QEMU under The One True License of the
>> day.
>
> 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 think there's 
anything wrong with GPLv3, I think that "or later" is a dangerous clause to add.

Regards,

Anthony Liguori

>
> IMO having old GPLv2-only code is one thing. But there's a lot of new
> GPLv2-only code cooking and occasionally pouring in, especially from
> qemu-kvm. Device assignment is a current example I encountered.
>
> If we could make checkpatch.pl detect new GPLv2-only code, then I would
> hope, given the dynamic QEMU development of the last few years, that the
> GPLv2-only portions become so small (both in relation and absolute) that
> they can either be replaced or the authors' permission be obtained to
> change the license to GPLv2-or-later.
>
> Andreas
>

Paolo Bonzini Oct. 17, 2011, 12:50 p.m. UTC | #10

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 think there's
> anything wrong with GPLv3, I think that "or later" is a dangerous clause
> to add.

License fragmentation with respect to the de facto standard toolchain 
(binutils) is wrong.  Until llvm includes support for as many obscure 
targets as we support in QEMU, some level of pragmatism might be necessary.

Paolo

Anthony Liguori Oct. 17, 2011, 2:17 p.m. UTC | #11

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 anything wrong with GPLv2 only. While I don't think there's
>> anything wrong with GPLv3, I think that "or later" is a dangerous clause
>> to add.
>
> 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 Linux 
too.  That puts us between a rock and a hard place.

Regards,

Anthony Liguori

> Until llvm includes support for as many obscure targets as we support
> in QEMU, some level of pragmatism might be necessary.
>
> Paolo
>

Paolo Bonzini Oct. 17, 2011, 2:27 p.m. UTC | #12

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 Linux too.  That puts us between a rock and a hard place.

We are a userspace package, though, and kernel headers are not 
copyrightable.  Unlike perf we do not define APIs, we're just a consumer 
even for KVM (by design!).

And when something we pull in is not headers (no example comes to mind), 
the copyright holder is quite often one of two well-known employers.

Paolo

Andreas Färber Oct. 17, 2011, 4:30 p.m. UTC | #13

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 code
>>>> and there will probably be a GPLv4 one day.
>>>
>>> I don't see anything wrong with GPLv2 only. While I don't think there's
>>> anything wrong with GPLv3, I think that "or later" is a dangerous clause
>>> to add.
>>
>> 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.

Tell that to the GNU and FSF people. :)

In my personal opinion, Open Source licenses should preserve our
freedom, not make us unnecessarily duplicate code.

I'm just asking to not make the situation worse than it is.

Regards,
Andreas

Andreas Färber Oct. 17, 2011, 4:39 p.m. UTC | #14

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
migration-unix.c
module.c
nbd.c
notify.c
pflib.c
posix-aio-compat.c
qemu-nbd.c
qemu-sockets.c
qemu-tool.c
xen-all.c
xen-mapcache.c
xen-stub.c

v2 or v3 only:
bt-host.c
bt-vhci.c


Andreas

Peter Maydell Oct. 17, 2011, 4:47 p.m. UTC | #15

On 17 October 2011 17:39, Andreas Färber <afaerber@suse.de> 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

Anthony Liguori Oct. 17, 2011, 4:47 p.m. UTC | #16

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 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 think there's
>>>> anything wrong with GPLv3, I think that "or later" is a dangerous clause
>>>> to add.
>>>
>>> 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.
>
> Tell that to the GNU and FSF people. :)
>
> In my personal opinion, Open Source licenses should preserve our
> freedom, not make us unnecessarily duplicate code.
>
> I'm just asking to not make the situation worse than it is.

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 read 
i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; done

Here's the results.  All of these people would have to explicitly SoB a 
relicense of that specific file to include a "v2 or later" clause.  In some 
cases, there's code from Thiemo which cannot be relicensed due to his untimely 
passing.

aio.c
   Alexander Graf <alex@csgraf.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andrea Arcangeli <aarcange@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Kevin Wolf <kwolf@redhat.com>
   Nolan <nolan@sigbus.net>
blockdev.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Christoph Hellwig <hch@lst.de>
   Eduardo Habkost <ehabkost@redhat.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Marcelo Tosatti <mtosatti@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Ryan Harper <ryanh@us.ibm.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
block-migration.c
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avishay Traeger <AVISHAY@il.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   Liran Schour <lirans@il.ibm.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Marcelo Tosatti <mtosatti@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Pierre Riteau <Pierre.Riteau@irisa.fr>
   Shahar Havivi <shaharh@redhat.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
buffered_file.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Glauber Costa <glommer@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Marcelo Tosatti <mtosatti@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Pierre Riteau <Pierre.Riteau@irisa.fr>
compatfd.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Jan Kiszka <jan.kiszka@siemens.com>
   Marcelo Tosatti <mtosatti@redhat.com>
   Tristan Gingold <gingold@adacore.com>
error.c
   Anthony Liguori <aliguori@us.ibm.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Stefan Weil <weil@mail.berlios.de>
hmp.c
   Anthony Liguori <aliguori@us.ibm.com>
   Luiz Capitulino <lcapitulino@redhat.com>
hw/a9mpcore.c
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
hw/ads7846.c
   Alex Williamson <alex.williamson@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/an5206.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/arm11mpcore.c
   Avi Kivity <avi@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   Peter Maydell <peter.maydell@linaro.org>
hw/arm_boot.c
   Adam Lackorzynski <adam@os.inf.tu-dresden.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/arm_gic.c
   Adam Lackorzynski <adam@os.inf.tu-dresden.de>
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/arm_pic.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andreas Färber <andreas.faerber@web.de>
   Jan Kiszka <jan.kiszka@siemens.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/arm_sysctl.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Daniel Jacobowitz <drow@false.org>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/arm_timer.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Rabin Vincent <rabin@rab.in>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/armv7m.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/armv7m_nvic.c
   Alex Williamson <alex.williamson@redhat.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/bitbang_i2c.c
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Marcus Comstedt <marcus@mc.pp.se>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
hw/bonito.c
   Alexander Graf <agraf@suse.de>
   Avi Kivity <avi@redhat.com>
   Huacai Chen <zltjiangshi@gmail.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Stefan Weil <weil@mail.berlios.de>
hw/collie.c
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
hw/ds1338.c
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
hw/dummy_m68k.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/ecc.c
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/empty_slot.c
   Alexander Graf <agraf@suse.de>
   Artyom Tarasenko <atar4qemu@googlemail.com>
   Stefan Weil <weil@mail.berlios.de>
hw/es1370.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Gerd Hoffmann <kraxel@redhat.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/event_notifier.c
   Michael S. Tsirkin <mst@redhat.com>
hw/fmopl.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Weil <weil@mail.berlios.de>
hw/framebuffer.c
   Anthony Liguori <aliguori@us.ibm.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   malc <av1474@comtv.ru>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Vasily Khoruzhick <anarsoul@gmail.com>
hw/gumstix.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/i2c.c
   Alex Williamson <alex.williamson@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Juha Riihimäki <Juha.Riihimaki@nokia.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/integratorcp.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/ivshmem.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Cam Macdonell <cam@cs.ualberta.ca>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jes Sorensen <Jes.Sorensen@redhat.com>
hw/kvmclock.c
   Glauber Costa <glommer@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Luiz Capitulino <lcapitulino@redhat.com>
hw/lan9118.c
   Alexander Graf <agraf@suse.de>
   Atsushi Nemoto <anemo@mba.ocn.ne.jp>
   Blue Swirl <blauwirbel@gmail.com>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   Peter Maydell <peter.maydell@linaro.org>
   Stefan Weil <weil@mail.berlios.de>
hw/lsi53c895a.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Bernhard Kohl <bernhard.kohl@nsn.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Christophe Fergeau <cfergeau@redhat.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   Laszlo Ast <laszlo.ast@siemens-enterprise.com>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Michael S. Tsirkin <mst@redhat.com>
   Nolan <nolan@sigbus.net>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Ryan Harper <ryanh@us.ibm.com>
   Sebastian Herbszt <herbszt@gmx.de>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mainstone.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/marvell_88w8618_audio.c
   Alexander Graf <agraf@suse.de>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Jan Kiszka <jan.kiszka@web.de>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
hw/max111x.c
   Alex Williamson <alex.williamson@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/max7310.c
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mcf5206.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mcf5208.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mcf_fec.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mcf_intc.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mcf_uart.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/mips_fulong2e.c
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Huacai Chen <zltjiangshi@gmail.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Stefan Weil <weil@mail.berlios.de>
hw/mpcore.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/msix.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   malc <av1474@comtv.ru>
   Michael S. Tsirkin <mst@redhat.com>
   Stefan Weil <weil@mail.berlios.de>
hw/mst_fpga.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/musicpal.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Benoit Canet <benoit.canet@gmail.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
hw/nand.c
   Alex Williamson <alex.williamson@redhat.com>
   Andrzej Zaborowski <andrew.zaborowski@intel.com>
   Anthony Liguori <aliguori@us.ibm.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Edgar E. Iglesias <edgar.iglesias@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Jean-Christophe DUBOIS <jcd@tribudubois.net>
   Juan Quintela <quintela@redhat.com>
   Juha Riihimäki <juha.riihimaki@nokia.com>
   Markus Armbruster <armbru@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pc.c
   Adam Lackorzynski <adam@os.inf.tu-dresden.de>
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Anthony PERARD <anthony.perard@citrix.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Aurelien Jarno <aurelien@aurel32.net>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   Bernhard Kohl <bernhard.kohl@nsn.com>
   Bernhard M. Wiedemann <qemudevbmw@lsmod.de>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
   Eduardo Habkost <ehabkost@redhat.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Glauber Costa <glommer@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   Jes Sorensen <jes@sgi.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162>
   Juan Quintela <quintela@redhat.com>
   Justin M. Forbes <jmforbes@linuxtx.org>
   Kevin Wolf <kwolf@redhat.com>
   Kirill A. Shutemov <kirill@shutemov.name>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@pond.sub.org>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   M. Mohan Kumar <mohan@in.ibm.com>
   Pascal Terjan <pterjan@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
   Richard W.M. Jones <rjones@redhat.com>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl011.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl022.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl050.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl061.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   Stefan Weil <weil@mail.berlios.de>
hw/pl080.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl110.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl181.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jan Kiszka <jan.kiszka@web.de>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pl190.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/ptimer.c
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Juan Quintela <quintela@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
   Vasily Khoruzhick <anarsoul@gmail.com>
hw/pxa2xx_dma.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx_gpio.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx_keypad.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Vasily Khoruzhick <anarsoul@gmail.com>
hw/pxa2xx_lcd.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Weil <weil@mail.berlios.de>
   Vasily Khoruzhick <anarsoul@gmail.com>
hw/pxa2xx_mmci.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx_pcmcia.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx_pic.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Andrzej Zaborowski <andrew.zaborowski@intel.com>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/pxa2xx_timer.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Andrzej Zaborowski <andrew.zaborowski@intel.com>
   Andrzej Zaborowski <balrog@zabor.org>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/realview.c
   Adam Lackorzynski <adam@os.inf.tu-dresden.de>
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/realview_gic.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/scsi-disk.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Artyom Tarasenko <atar4qemu@googlemail.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   Bernhard Kohl <bernhard.kohl@nsn.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Christoph Hellwig <hch@lst.de>
   Gerd Hoffmann <kraxel@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Herve Poussineau <hpoussin@reactos.org>
   Jan Kiszka <jan.kiszka@siemens.com>
   Kevin Wolf <kwolf@redhat.com>
   Laszlo Ast <laszlo.ast@siemens-enterprise.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Naphtali Sprei <nsprei@redhat.com>
   Paolo Bonzini <pbonzini@redhat.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/scsi-generic.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Bernhard Kohl <bernhard.kohl@nsn.com>
   Blue Swirl <blauwirbel@gmail.com>
   Christoph Hellwig <hch@lst.de>
   Gerd Hoffmann <kraxel@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Jean-Christophe DUBOIS <jcd@tribudubois.net>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/sh_intc.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/sh_timer.c
   Alexander Graf <agraf@suse.de>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/smbios.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Beth Kon <eak@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Stefan Weil <weil@mail.berlios.de>
hw/smbus.c
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/smc91c111.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juha Riihimäki <juha.riihimaki@nokia.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/spitz.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Juha Riihimäki <juha.riihimaki@nokia.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   Richard Henderson <rth@twiddle.net>
   Stefan Weil <weil@mail.berlios.de>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/ssd0303.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Weil <weil@mail.berlios.de>
hw/ssd0323.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/ssi.c
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
hw/ssi-sd.c
   Alex Williamson <alex.williamson@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/stellaris.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Engin AYDOGAN <engin@bzzzt.biz>
   Gerd Hoffmann <kraxel@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/stellaris_enet.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/stellaris_input.c
   Alex Williamson <alex.williamson@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Juan Quintela <quintela@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/strongarm.c
   Anthony Liguori <aliguori@us.ibm.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Markus Armbruster <armbru@redhat.com>
hw/tc6393xb.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Juha Riihimäki <juha.riihimaki@nokia.com>
   malc <av1474@comtv.ru>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
hw/tosa.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Lars Munch <lars@segv.dk>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Richard Henderson <rth@twiddle.net>
hw/usb-msd.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Brad Hards <bradh@frogmouth.net>
   Christoph Hellwig <hch@lst.de>
   Gerd Hoffmann <kraxel@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Hans de Goede <hdegoede@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Max Reitz <max@tyndur.org>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/usb-serial.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Brad Hards <bradh@frogmouth.net>
   David S. Ahern <daahern@cisco.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Hans de Goede <hdegoede@redhat.com>
   Jason Wessel <jason.wessel@windriver.com>
   Kevin Wolf <kwolf@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Paul Brook <paul@codesourcery.com>
hw/versatilepb.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Avi Kivity <avi@redhat.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162>
   malc <av1474@comtv.ru>
   Markus Armbruster <armbru@redhat.com>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/versatile_pci.c
   Alexander Graf <agraf@suse.de>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   Matthew Fernandez <matthew.fernandez@gmail.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Peter Maydell <peter.maydell@linaro.org>
   ths <ths@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/vhost.c
   Anthony Liguori <aliguori@us.ibm.com>
   Anthony PERARD <anthony.perard@citrix.com>
   Blue Swirl <blauwirbel@gmail.com>
   Jason Wang <jasowang@redhat.com>
   Marcelo Tosatti <mtosatti@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Mike McCormack <mikem@ring3k.org>
   mst@redhat.com <mst@redhat.com>
   Stefan Weil <weil@mail.berlios.de>
hw/vhost_net.c
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Michael Tokarev <mjt@tls.msk.ru>
   Mike McCormack <mikem@ring3k.org>
   mst@redhat.com <mst@redhat.com>
hw/virtio-balloon.c
   Adam Litke <agl@us.ibm.com>
   Alexey Kardashevskiy <aik@ozlabs.ru>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Andreas Färber <afaerber@opensolaris.org>
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Eduardo Habkost <ehabkost@redhat.com>
   malc <av1474@comtv.ru>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/virtio-blk.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Aurelien Jarno <aurelien@aurel32.net>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Bruce Rogers <brogers@novell.com>
   Christoph Hellwig <hch@lst.de>
   Gerd Hoffmann <kraxel@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   hch@lst.de <hch@lst.de>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   john cooper <john.cooper@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Naphtali Sprei <nsprei@redhat.com>
   Paul Brook <paul@codesourcery.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Stefan Weil <weil@mail.berlios.de>
   Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
hw/virtio.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   David Gibson <david@gibson.dropbear.id.au>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jason Wang <jasowang@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Stefan Weil <weil@mail.berlios.de>
hw/virtio-console.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Gerd Hoffmann <kraxel@redhat.com>
   Hans de Goede <hdegoede@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
hw/virtio-net.c
   Alex Williamson <alex.williamson@hp.com>
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Aurelien Jarno <aurelien@aurel32.net>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   David L Stevens <dlstevens@us.ibm.com>
   Dustin Kirkland <kirkland@canonical.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Glauber Costa <glommer@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   mst@redhat.com <mst@redhat.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Paul Brook <paul@codesourcery.com>
   Sridhar Samudrala <sri@us.ibm.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Tom Lendacky <tahm@linux.vnet.ibm.com>
hw/virtio-pci.c
   Alexander Graf <agraf@suse.de>
   Alex Williamson <alex.williamson@redhat.com>
   Amit Shah <amit.shah@redhat.com>
   Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   Christoph Hellwig <hch@lst.de>
   Gerd Hoffmann <kraxel@redhat.com>
   Gleb Natapov <gleb@redhat.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Jan Kiszka <jan.kiszka@web.de>
   malc <av1474@comtv.ru>
   Mark McLoughlin <markmc@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   mst@redhat.com <mst@redhat.com>
   Paul Brook <paul@codesourcery.com>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
   Yan Vugenfirer <yvugenfi@redhat.com>
hw/virtio-serial-bus.c
   Alexey Kardashevskiy <aik@ozlabs.ru>
   Alex Williamson <alex.williamson@redhat.com>
   Alon Levy <alevy@redhat.com>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Hannes Reinecke <hare@suse.de>
   Luiz Capitulino <lcapitulino@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
hw/vt82c686.c
   Huacai Chen <zltjiangshi@gmail.com>
   Isaku Yamahata <yamahata@valinux.co.jp>
   Paolo Bonzini <pbonzini@redhat.com>
   Richard Henderson <rth@twiddle.net>
   Stefan Weil <weil@mail.berlios.de>
hw/wm8750.c
   Anthony Liguori <aliguori@us.ibm.com>
   balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Juan Quintela <quintela@redhat.com>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Paul Brook <paul@codesourcery.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
hw/z2.c
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Richard Henderson <rth@twiddle.net>
   Vasily Khoruzhick <anarsoul@gmail.com>
iov.c
   Amit Shah <amit.shah@redhat.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Hannes Reinecke <hare@suse.de>
memory.c
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   Blue Swirl <blauwirbel@gmail.com>
   David Gibson <david@gibson.dropbear.id.au>
   Jan Kiszka <jan.kiszka@siemens.com>
   Michael Walle <michael@walle.cc>
   Richard Henderson <rth@twiddle.net>
migration.c
   Alex Williamson <alex.williamson@redhat.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Amit Shah <amit.shah@redhat.com>
   Anthony Liguori <aliguori@us.ibm.com>
   Chris Lalancette <clalance@redhat.com>
   Gerd Hoffmann <kraxel@redhat.com>
   Glauber Costa <glommer@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   Juan Quintela <quintela@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   malc <av1474@comtv.ru>
   Marcelo Tosatti <mtosatti@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Michael S. Tsirkin <mst@redhat.com>
   Paolo Bonzini <pbonzini@redhat.com>
   Uri Lublin <uril@redhat.com>
   Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
migration-exec.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Chris Lalancette <clalance@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Paolo Bonzini <pbonzini@redhat.com>
migration-fd.c
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Paolo Bonzini <pbonzini@redhat.com>
migration-tcp.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Paolo Bonzini <pbonzini@redhat.com>
   Shahar Havivi <shaharh@redhat.com>
   Stefan Weil <weil@mail.berlios.de>
   Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
migration-unix.c
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
   Chris Lalancette <clalance@redhat.com>
   Daniel P. Berrange <berrange@redhat.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Juan Quintela <quintela@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   lirans@il.ibm.com <lirans@il.ibm.com>
   malc <av1474@comtv.ru>
   Stefan Weil <weil@mail.berlios.de>
module.c
   Anthony Liguori <aliguori@us.ibm.com>
   Blue Swirl <blauwirbel@gmail.com>
notify.c
   Anthony Liguori <aliguori@us.ibm.com>
   Jan Kiszka <jan.kiszka@siemens.com>
pflib.c
   Anthony Liguori <aliguori@us.ibm.com>
   Gerd Hoffmann <kraxel@redhat.com>
posix-aio-compat.c
   Alexandre Raymond <cerbere@gmail.com>
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Andrew de Quincey <adq@lidskialf.net>
   Anthony Liguori <aliguori@us.ibm.com>
   Avi Kivity <avi@redhat.com>
   blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Christoph Hellwig <hch@lst.de>
   Frediano Ziglio <freddy77@gmail.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   Kirill A. Shutemov <kirill@shutemov.name>
   malc <av1474@comtv.ru>
   malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
   Stefan Weil <weil@mail.berlios.de>
qemu-tool.c
   aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
   Anthony Liguori <aliguori@us.ibm.com>
   aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162>
   Blue Swirl <blauwirbel@gmail.com>
   Frediano Ziglio <freddy77@gmail.com>
   Jes Sorensen <Jes.Sorensen@redhat.com>
   Juan Quintela <quintela@redhat.com>
   Kevin Wolf <kwolf@redhat.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Markus Armbruster <armbru@redhat.com>
   Naphtali Sprei <nsprei@redhat.com>
   pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162>
   Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
qmp.c
   Anthony Liguori <aliguori@us.ibm.com>
   Luiz Capitulino <lcapitulino@redhat.com>
xen-all.c
   Anthony Liguori <aliguori@us.ibm.com>
   Anthony PERARD <anthony.perard@citrix.com>
   Arun Sharma <arun.sharma@intel.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   Jun Nakajima <jun.nakajima@intel.com>
   Luiz Capitulino <lcapitulino@redhat.com>
   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-mapcache.c
   Anthony Liguori <aliguori@us.ibm.com>
   Anthony PERARD <anthony.perard@citrix.com>
   Jan Kiszka <jan.kiszka@siemens.com>
   John Baboval <john.baboval@virtualcomputer.com>
   Jun Nakajima <jun.nakajima@intel.com>
   Stefan Berger <stefanb@linux.vnet.ibm.com>
   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-stub.c
   Anthony PERARD <anthony.perard@citrix.com>
   Jun Nakajima <jun.nakajima@intel.com>
   Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Regards,

Anthony Liguori

>
> Regards,
> Andreas
>

Anthony Liguori Oct. 17, 2011, 4:51 p.m. UTC | #17

On 10/17/2011 11:47 AM, Peter Maydell wrote:
> On 17 October 2011 17:39, Andreas Färber<afaerber@suse.de>  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.

Including binutils code is just a bad idea.  I know noone wants to hear that but 
it's unfortunately true.

The FSF does copyright assignment which means it's easy for them to relicense. 
Since we don't do copyright assignment, it's much, much harder for us to 
relicense.  We'd waste huge amounts of man hours trying to chase binutils license.

We need to stick with the v2 version of binutils and perhaps work toward an 
alternative in the future.  Relicensing is just not practical.

Regards,

Anthony Liguori

>
> -- PMM
>

Andreas Färber Oct. 17, 2011, 5:01 p.m. UTC | #18

Am 17.10.2011 18:47, schrieb Peter Maydell:
> On 17 October 2011 17:39, Andreas Färber <afaerber@suse.de> 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.

I know. I didn't claim it was complete.

Andreas

Stefan Weil Oct. 17, 2011, 5:46 p.m. UTC | #19

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 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 think 
>>>>> there's
>>>>> anything wrong with GPLv3, I think that "or later" is a dangerous 
>>>>> clause
>>>>> to add.
>>>>
>>>> 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.
>>
>> Tell that to the GNU and FSF people. :)
>>
>> In my personal opinion, Open Source licenses should preserve our
>> freedom, not make us unnecessarily duplicate code.
>>
>> I'm just asking to not make the situation worse than it is.
>
> 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 read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; 
> done
>
> Here's the results.  All of these people would have to explicitly SoB 
> a relicense of that specific file to include a "v2 or later" clause.  
> In some cases, there's code from Thiemo which cannot be relicensed due 
> to his untimely passing.


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'd appreciate if no new files were published with GPL v2 only.

Stefan W.

PS. I no longer use my old email address because Berlios
will be closed on 2011-12-31, see http://www.berlios.de/.

Andreas Färber Oct. 17, 2011, 5:52 p.m. UTC | #20

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 read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; done

This fires on "or (at your option) any later version" and variations
thereof, including line breaks after "or" (e.g., blockdev.c).
Also for older files the SVN usernames appear as duplicates.
For SVN and CVS commits we'd additionally have to check the commit
message for whether the committer received the code from another author.

Of the list, 90% seem regular contributors.

I didn't say resolving the issue would be possible in a day. Introducing
more GPLv2-only code will make it even more work though.

Andreas

Andreas Färber Oct. 17, 2011, 5:58 p.m. UTC | #21

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

Anthony Liguori Oct. 17, 2011, 6:16 p.m. UTC | #22

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 for interactive debugging, right?

Regards,

Anthony Liguori

>
> Andreas
>

Peter Maydell Oct. 17, 2011, 6:18 p.m. UTC | #23

On 17 October 2011 19:16, Anthony Liguori <anthony@codemonkey.ws> 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?

Also in the -d logs for non-interactive debugging.

-- PMM

Stefan Weil Oct. 17, 2011, 6:20 p.m. UTC | #24

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 disassembler?
>
> Sure.  This is only used in the monitor for interactive debugging, right?

The disassembler is also used with -d in_asm or -d out_asm to write 
qemu.log.
I expect that a pipe to an external disassembler would slow down 
execution with -d
significantly.

Regards,
Stefan Weil

Anthony Liguori Oct. 17, 2011, 6:29 p.m. UTC | #25

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 code
>>> from QEMU into an external disassembler?
>>
>> Sure. This is only used in the monitor for interactive debugging, right?
>
> The disassembler is also used with -d in_asm or -d out_asm to write qemu.log.
> I expect that a pipe to an external disassembler would slow down execution with -d
> significantly.

How difficult would it be to add tracing to tcg-target.c such that you could get 
out_asm that way?

At least with i386, there's just a few instruction forms so it should just be a 
matter of a few trace points with a table of opcode names.

Likewise, we could add tracing to translate.c to achieve the same affect as in_asm.

Tracing's probably a far better approach for debugging as you would be able to 
do some very interesting things with SystemTap and such a mechanism.

Regards,

Anthony Liguori

> Regards,
> Stefan Weil
>
>

Peter Maydell Oct. 17, 2011, 6:34 p.m. UTC | #26

On 17 October 2011 19:29, Anthony Liguori <anthony@codemonkey.ws> 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 independent crosscheck of what's actually going in). I'd
rather have the logging dump plain hex to postprocess with objdump...

-- PMM

Anthony Liguori Oct. 17, 2011, 6:37 p.m. UTC | #27

On 10/17/2011 01:34 PM, Peter Maydell wrote:
> On 17 October 2011 19:29, Anthony Liguori<anthony@codemonkey.ws>  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 independent crosscheck of what's actually going in). I'd
> rather have the logging dump plain hex to postprocess with objdump...

Fair enough.

Regards,

Anthony Liguori

>
> -- PMM
>

Blue Swirl Oct. 17, 2011, 7:29 p.m. UTC | #28

On Mon, Oct 17, 2011 at 5:46 PM, Stefan Weil <sw@weilnetz.de> 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, 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 think
>>>>>> there's
>>>>>> anything wrong with GPLv3, I think that "or later" is a dangerous
>>>>>> clause
>>>>>> to add.
>>>>>
>>>>> 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.
>>>
>>> Tell that to the GNU and FSF people. :)
>>>
>>> In my personal opinion, Open Source licenses should preserve our
>>> freedom, not make us unnecessarily duplicate code.
>>>
>>> I'm just asking to not make the situation worse than it is.
>>
>> 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 read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; done
>>
>> Here's the results.  All of these people would have to explicitly SoB a
>> relicense of that specific file to include a "v2 or later" clause.  In some
>> cases, there's code from Thiemo which cannot be relicensed due to his
>> untimely passing.
>
>
> 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.

Me too, I'd also accept any other GPL v2 or v3 compatible licenses.

> I'd appreciate if no new files were published with GPL v2 only.

This could be more difficult.

> Stefan W.
>
> PS. I no longer use my old email address because Berlios
> will be closed on 2011-12-31, see http://www.berlios.de/.
>
>

Blue Swirl Oct. 17, 2011, 7:33 p.m. UTC | #29

On Mon, Oct 17, 2011 at 6:29 PM, Anthony Liguori <anthony@codemonkey.ws> 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 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 for interactive debugging, right?
>>
>> The disassembler is also used with -d in_asm or -d out_asm to write
>> qemu.log.
>> I expect that a pipe to an external disassembler would slow down execution
>> with -d
>> significantly.
>
> How difficult would it be to add tracing to tcg-target.c such that you could
> get out_asm that way?
>
> At least with i386, there's just a few instruction forms so it should just
> be a matter of a few trace points with a table of opcode names.
>
> Likewise, we could add tracing to translate.c to achieve the same affect as
> in_asm.
>
> Tracing's probably a far better approach for debugging as you would be able
> to do some very interesting things with SystemTap and such a mechanism.

Disassembly could be moved offline, so performance would also be
better and *_asm generation could be toggled dynamically.

> Regards,
>
> Anthony Liguori
>
>> Regards,
>> Stefan Weil
>>
>>
>
>
>

Blue Swirl Oct. 17, 2011, 7:43 p.m. UTC | #30

On Mon, Oct 17, 2011 at 4:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/17/2011 11:47 AM, Peter Maydell wrote:
>>
>> On 17 October 2011 17:39, Andreas Färber<afaerber@suse.de>  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.
>
> Including binutils code is just a bad idea.  I know noone wants to hear that
> but it's unfortunately true.

Some targets like Alpha, m68k and Sparc32 are not evolving anymore, so
binutils from 2007 will be fine forever. In other cases, the
manufacturers are adding new instructions (x86, ARM and Sparc64), then
a modern disassembler would be more and more useful over time.

> The FSF does copyright assignment which means it's easy for them to
> relicense. Since we don't do copyright assignment, it's much, much harder
> for us to relicense.  We'd waste huge amounts of man hours trying to chase
> binutils license.

Even with copyright assignment, our relicensing could conflict with theirs.

> We need to stick with the v2 version of binutils and perhaps work toward an
> alternative in the future.  Relicensing is just not practical.
>
> Regards,
>
> Anthony Liguori
>
>>
>> -- PMM
>>
>
>
>

Avi Kivity Oct. 17, 2011, 8:44 p.m. UTC | #31

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 well.

Markus Armbruster Oct. 18, 2011, 8:01 a.m. UTC | #32

Avi Kivity <avi@redhat.com> 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 can be relicensed to v2+ as well.

Plenty of precedence for that.

Anthony Liguori Oct. 18, 2011, 1:03 p.m. UTC | #33

On 10/18/2011 03:01 AM, Markus Armbruster wrote:
> Avi Kivity<avi@redhat.com>  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 can be relicensed to v2+ as well.
>
> Plenty of precedence for that.
>

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 getting approval at IBM.  Between RH, IBM, and 
Blue, there's a pretty large chunk of files that can be relicensed immediately. 
  It's probably best to tackle this incrementally.

Regards,

Anthony Liguori

Andreas Färber Oct. 18, 2011, 2:33 p.m. UTC | #34

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 getting approval at
> IBM.  Between RH, IBM, and Blue, there's a pretty large chunk of files
> that can be relicensed immediately.  It's probably best to tackle this
> incrementally.

Sounds like a plan, thanks.

The file list still has some false positives. Might edit later.
In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too.

A few files are completely lacking a license btw.

Andreas

Anthony Liguori Oct. 18, 2011, 2:36 p.m. UTC | #35

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 wiki.  I'm in the process of getting approval at
>> IBM.  Between RH, IBM, and Blue, there's a pretty large chunk of files
>> that can be relicensed immediately.  It's probably best to tackle this
>> incrementally.
>
> Sounds like a plan, thanks.
>
> The file list still has some false positives. Might edit later.
> In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too.

Yes, please edit the wiki.  I just attempted to post a strawman to get us started.

> A few files are completely lacking a license btw.

Yes, we'll have to list those separately, contact the original author to add a 
copyright statement+license, and get every contributor to SoB the change.

Regards,

Anthony Liguori

> Andreas
>

nicolas.sauzede Oct. 18, 2011, 2:44 p.m. UTC | #36

Some files are not even listed, such as hw/vexpress.c, which seem to be GPL v2 (only)..


> Message du 18/10/11 16:37
> De : "Anthony Liguori"
> A : "Andreas Färber"
> Copie à : "Stefan Weil" , qemu-devel@nongnu.org, "Markus Armbruster" , "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'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 getting approval at
> >> IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files
> >> that can be relicensed immediately. It's probably best to tackle this
> >> incrementally.
> >
> > Sounds like a plan, thanks.
> >
> > The file list still has some false positives. Might edit later.
> > In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too.
>
> Yes, please edit the wiki. I just attempted to post a strawman to get us started.
>
> > A few files are completely lacking a license btw.
>
> Yes, we'll have to list those separately, contact the original author to add a
> copyright statement+license, and get every contributor to SoB the change.
>
> Regards,
>
> Anthony Liguori
>
> > Andreas
> >
>
>
> 

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

andrzej zaborowski Oct. 18, 2011, 3 p.m. UTC | #37

On 18 October 2011 15:03, Anthony Liguori <anthony@codemonkey.ws> 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 to be GPLv2+ but
the header had been copy&pasted.  Where I'm the copyright owner I
agree for them to be put under any later GPL version.  Other SVN
contributors need to be looked up in the svn commit messages. (that
section's heading is missing a "not"?)

Cheers

Peter Maydell Oct. 18, 2011, 3:19 p.m. UTC | #38

On 18 October 2011 14:03, Anthony Liguori <anthony@codemonkey.ws> 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 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 the
omap support which have gone through several people (listed in
the Signed-off-by: lines) who all have copyright-authorship even
if they're not git-commit-authors.

-- PMM

Paolo Bonzini Oct. 18, 2011, 3:31 p.m. UTC | #39

On 10/18/2011 05:19 PM, Peter Maydell wrote:
> On 18 October 2011 14:03, Anthony Liguori<anthony@codemonkey.ws>  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 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 the
> omap support which have gone through several people (listed in
> the Signed-off-by: lines) who all have copyright-authorship even
> if they're not git-commit-authors.

Yes, also just to get it written somewhere: the list of copyright 
holders is merely indicative.

Anyway, unfortunately this is, I think, a lost battle.  For linux-user 
there's too much Linux kernel code.  It would still be nice to not 
introduce more GPLv2-only code, but don't hold your breath...

Paolo

Anthony Liguori Oct. 18, 2011, 3:56 p.m. UTC | #40

On 10/18/2011 10:19 AM, Peter Maydell wrote:
> On 18 October 2011 14:03, Anthony Liguori<anthony@codemonkey.ws>  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 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 the
> omap support which have gone through several people (listed in
> the Signed-off-by: lines) who all have copyright-authorship even
> if they're not git-commit-authors.

Sure, but the Author shouldn't Signed-off-by on a copyright change if there are 
other copyright owners that also need to approve.  SoB is stating that you are 
entitled to submit the patch which in case of copyright change means you own the 
copyright or got permission from the copyright owner.

That's why we should have all authors include a SoB.  It provides the paper 
trail of anyone who may have touched the file.

Regards,

Anthony Liguori

>
> -- PMM
>

Anthony Liguori Oct. 18, 2011, 4:01 p.m. UTC | #41

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<anthony@codemonkey.ws> 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 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 the
>> omap support which have gone through several people (listed in
>> the Signed-off-by: lines) who all have copyright-authorship even
>> if they're not git-commit-authors.
>
> Yes, also just to get it written somewhere: the list of copyright holders is
> merely indicative.
>
> Anyway, unfortunately this is, I think, a lost battle. For linux-user there's
> too much Linux kernel code.


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.   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.

Regards,

Anthony Liguori

  It would still be nice to not introduce more
> GPLv2-only code, but don't hold your breath...
>
> Paolo
>

Peter Maydell Oct. 18, 2011, 4:14 p.m. UTC | #42

On 18 October 2011 16:56, Anthony Liguori <anthony@codemonkey.ws> 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 the
>> omap support which have gone through several people (listed in
>> the Signed-off-by: lines) who all have copyright-authorship even
>> if they're not git-commit-authors.
>
> Sure, but the Author shouldn't Signed-off-by on a copyright change if there
> are other copyright owners that also need to approve.  SoB is stating that
> you are entitled to submit the patch which in case of copyright change means
> you own the copyright or got permission from the copyright owner.

Yes, you need "permission from the copyright owner", but that
only amounts to "permission from the copyright owner to submit
under this license", not "permission to relicense the code as
you feel like later". (cf clause (b) of the "Developer's Certificate
of Origin".)

That document also says later that you can modify the change as
you pass it up providing you add your signed-off-by too, so the
whole set of people who signed-off-by some patch are potentially
copyright-authors, which was my original point.

-- PMM

Peter Maydell Oct. 18, 2011, 4:15 p.m. UTC | #43

On 18 October 2011 17:01, Anthony Liguori <anthony@codemonkey.ws> 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 move to GPLv3 in the first place, right?

-- PMM

Avi Kivity Oct. 18, 2011, 4:20 p.m. UTC | #44

On 10/18/2011 06:15 PM, Peter Maydell wrote:
> On 18 October 2011 17:01, Anthony Liguori <anthony@codemonkey.ws> 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 move to GPLv3 in the first place, right?
>

That code is packaged in libopcodes.so, so if that is LGPLv3 we can link
it in.

However, it may not be available on all systems, and I don't think
cross-disassemblers are installed by default.

Perhaps we can make it an optional component loaded with dlopen()?  Most
users will never use the integrated disassembler.

Anthony Liguori Oct. 18, 2011, 4:30 p.m. UTC | #45

On 10/18/2011 11:15 AM, Peter Maydell wrote:
> On 18 October 2011 17:01, Anthony Liguori<anthony@codemonkey.ws>  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 move to GPLv3 in the first place, right?

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.

Regards,

Anthony Liguori

>
> -- PMM
>

Peter Maydell Oct. 18, 2011, 4:32 p.m. UTC | #46

On 18 October 2011 17:30, Anthony Liguori <anthony@codemonkey.ws> 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.

Yuck. Please don't make linux-user a second class citizen like that.

-- PMM

Paolo Bonzini Oct. 18, 2011, 4:37 p.m. UTC | #47

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 simplest thing to do is to really implement a binary format to 
store (or pipe) in_asm and out_asm traces.  Then the trace dumper could 
use all the binutils code it wants to, and would be the only thing 
requiring a v3 license.  in_asm/out_asm traces are so huge that this 
thing does have some actual benefit if somebody wants to write it.

That said, it is still nice if we can get people to agree on relicensing 
what they own, if only to help sharing code with other GPL programs. 
With the obvious exception of MIPS and linux-user, it does not seem 
impossible, though indeed hard, and it is also a good occasion to clean 
up files without a license.

Paolo

Blue Swirl Oct. 18, 2011, 6:44 p.m. UTC | #48

On Tue, Oct 18, 2011 at 4:37 PM, Paolo Bonzini <pbonzini@redhat.com> 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 linux-user.  Both repos could
>> pull in TCG as a submodule.
>
> Nah, the simplest thing to do is to really implement a binary format to
> store (or pipe) in_asm and out_asm traces.  Then the trace dumper could use
> all the binutils code it wants to, and would be the only thing requiring a
> v3 license.  in_asm/out_asm traces are so huge that this thing does have
> some actual benefit if somebody wants to write it.

This would work for linux-user since the there is no monitor, so
linux-user could be left as GPLv2.

For the system emulators, it would be a small improvement for in_asm
or out_asm logs, but the builtin monitor disassembly command would
have to fork and exec this external tool. But if that's the only
unsolved case, perhaps that feature could be made conditional to
libopcodes.so instead.

> That said, it is still nice if we can get people to agree on relicensing
> what they own, if only to help sharing code with other GPL programs. With
> the obvious exception of MIPS and linux-user, it does not seem impossible,
> though indeed hard, and it is also a good occasion to clean up files without
> a license.

Yes, I'd still try to get other files relicensed.

Dor Laor Oct. 25, 2011, 2:34 p.m. UTC | #49

On 10/18/2011 03:03 PM, Anthony Liguori wrote:
> On 10/18/2011 03:01 AM, Markus Armbruster wrote:
>> Avi Kivity<avi@redhat.com> 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 can be relicensed to v2+ as well.
>>
>> Plenty of precedence for that.
>>
>
> 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

> instructions on the wiki. I'm in the process of getting approval at IBM.
> Between RH, IBM, and Blue, there's a pretty large chunk of files that
> can be relicensed immediately. It's probably best to tackle this
> incrementally.
>
> Regards,
>
> Anthony Liguori
>

Stefan Weil Jan. 25, 2012, 9:16 p.m. UTC | #50

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
>
>> instructions on the wiki. I'm in the process of getting approval at IBM.
>> Between RH, IBM, and Blue, there's a pretty large chunk of files that
>> can be relicensed immediately. It's probably best to tackle this
>> incrementally.
>>
>> Regards,
>>
>> Anthony Liguori
>

Hi Anthony,

maybe I missed a mail, but did you get approval for GPLv2+ at IBM?

http://wiki.qemu.org/Relicensing#Commitments_to_Relicense
still does not list IBM.

Regards,

Stefan W.

Michael Walle Jan. 26, 2012, 6:05 p.m. UTC | #51

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.

[6/7] target-xtensa: add fsf core

Commit Message

Comments

Patch