From: Scott Wood <scottwood@freescale.com>
To: Avi Kivity <avi@redhat.com>
Cc: agraf@suse.de, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Liu Yu <yu.liu@freescale.com>,
Varun Sethi <varun.sethi@freescale.com>
Subject: Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
Date: Tue, 10 Jan 2012 22:20:39 +0000 [thread overview]
Message-ID: <4F0CB9B7.9020607@freescale.com> (raw)
In-Reply-To: <4F0BF8BB.4080309@redhat.com>
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their signoff directly on the new patches, since I didn't want to make
>> it look like they had submitted the patch in anything resembling its
>> current form. I wanted to give them credit for what they did, but not
>> blame for what I did with their code.
>>
>
> Signoffs are for assigning neither credit nor blame, but for
> attributing authorship and affirming that a contributor has
> the right to contribute code or pass it along.
That's its formal purpose, but some people draw other conclusions from
it regardless. From Documentation/SubmittingPatches: "Rule (b) allows
you to adjust the code, but then it is very impolite to change one
submitter's code and make him endorse your bugs."
Please read the DCO at
> https://lwn.net/Articles/437739/.
I've read it. My signoff here qualifies based on (a) and (b).
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
Note "or in part". The contributions in this patch were all produced by
Freescale employees on a work for hire basis (other than the extent to
which the code is derived from code already in the Linux kernel, which
is covered by (b)), and I am authorized to submit this work on
Freescale's behalf for inclusion into the Linux kernel under GPLv2.
I'm not trying to be difficult, just to avoid looking like it was a
patch passed more-or-less as-is from person to person. When I resubmit,
I can put the sign-offs in with [scottwood@freescale.com: significant
rework] after them, or list them separately as part of the "based on..."
paragraph.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Avi Kivity <avi@redhat.com>
Cc: Liu Yu <yu.liu@freescale.com>,
kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
Varun Sethi <varun.sethi@freescale.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
Date: Tue, 10 Jan 2012 16:20:39 -0600 [thread overview]
Message-ID: <4F0CB9B7.9020607@freescale.com> (raw)
In-Reply-To: <4F0BF8BB.4080309@redhat.com>
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their signoff directly on the new patches, since I didn't want to make
>> it look like they had submitted the patch in anything resembling its
>> current form. I wanted to give them credit for what they did, but not
>> blame for what I did with their code.
>>
>
> Signoffs are for assigning neither credit nor blame, but for
> attributing authorship and affirming that a contributor has
> the right to contribute code or pass it along.
That's its formal purpose, but some people draw other conclusions from
it regardless. From Documentation/SubmittingPatches: "Rule (b) allows
you to adjust the code, but then it is very impolite to change one
submitter's code and make him endorse your bugs."
Please read the DCO at
> https://lwn.net/Articles/437739/.
I've read it. My signoff here qualifies based on (a) and (b).
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
Note "or in part". The contributions in this patch were all produced by
Freescale employees on a work for hire basis (other than the extent to
which the code is derived from code already in the Linux kernel, which
is covered by (b)), and I am authorized to submit this work on
Freescale's behalf for inclusion into the Linux kernel under GPLv2.
I'm not trying to be difficult, just to avoid looking like it was a
patch passed more-or-less as-is from person to person. When I resubmit,
I can put the sign-offs in with [scottwood@freescale.com: significant
rework] after them, or list them separately as part of the "based on..."
paragraph.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Avi Kivity <avi@redhat.com>
Cc: <agraf@suse.de>, <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, Liu Yu <yu.liu@freescale.com>,
Varun Sethi <varun.sethi@freescale.com>
Subject: Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
Date: Tue, 10 Jan 2012 16:20:39 -0600 [thread overview]
Message-ID: <4F0CB9B7.9020607@freescale.com> (raw)
In-Reply-To: <4F0BF8BB.4080309@redhat.com>
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their signoff directly on the new patches, since I didn't want to make
>> it look like they had submitted the patch in anything resembling its
>> current form. I wanted to give them credit for what they did, but not
>> blame for what I did with their code.
>>
>
> Signoffs are for assigning neither credit nor blame, but for
> attributing authorship and affirming that a contributor has
> the right to contribute code or pass it along.
That's its formal purpose, but some people draw other conclusions from
it regardless. From Documentation/SubmittingPatches: "Rule (b) allows
you to adjust the code, but then it is very impolite to change one
submitter's code and make him endorse your bugs."
Please read the DCO at
> https://lwn.net/Articles/437739/.
I've read it. My signoff here qualifies based on (a) and (b).
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
Note "or in part". The contributions in this patch were all produced by
Freescale employees on a work for hire basis (other than the extent to
which the code is derived from code already in the Linux kernel, which
is covered by (b)), and I am authorized to submit this work on
Freescale's behalf for inclusion into the Linux kernel under GPLv2.
I'm not trying to be difficult, just to avoid looking like it was a
patch passed more-or-less as-is from person to person. When I resubmit,
I can put the sign-offs in with [scottwood@freescale.com: significant
rework] after them, or list them separately as part of the "based on..."
paragraph.
-Scott
next prev parent reply other threads:[~2012-01-10 22:20 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 1:33 [RFC PATCH 00/16] KVM: PPC: e500mc support Scott Wood
2011-12-21 1:33 ` Scott Wood
2011-12-21 1:33 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 15:21 ` Alexander Graf
2012-01-09 15:21 ` Alexander Graf
2012-01-09 15:21 ` Alexander Graf
2012-01-09 19:14 ` [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on Scott Wood
2012-01-09 19:14 ` [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit Scott Wood
2012-01-09 19:14 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 02/16] powerpc/e500: split Scott Wood
2011-12-21 1:34 ` [RFC PATCH 02/16] powerpc/e500: split CPU_FTRS_ALWAYS/CPU_FTRS_POSSIBLE Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 03/16] KVM: PPC: Use pt_regs in vcpu->arch Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 04/16] KVM: PPC: factor out lpid allocator from Scott Wood
2011-12-21 1:34 ` [RFC PATCH 04/16] KVM: PPC: factor out lpid allocator from book3s_64_mmu_hv Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 15:35 ` Alexander Graf
2012-01-09 15:35 ` Alexander Graf
2012-01-09 15:35 ` Alexander Graf
2012-01-12 4:16 ` Paul Mackerras
2012-01-12 4:16 ` Paul Mackerras
2012-01-12 4:16 ` Paul Mackerras
2011-12-21 1:34 ` [RFC PATCH 05/16] KVM: PPC: booke: add booke-level vcpu load/put Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 06/16] KVM: PPC: booke: Move vm core init/destroy out of Scott Wood
2011-12-21 1:34 ` [RFC PATCH 06/16] KVM: PPC: booke: Move vm core init/destroy out of booke.c Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 07/16] KVM: PPC: e500: rename e500_tlb.h to e500.h Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 08/16] KVM: PPC: e500: merge <asm/kvm_e500.h> into Scott Wood
2011-12-21 1:34 ` [RFC PATCH 08/16] KVM: PPC: e500: merge <asm/kvm_e500.h> into arch/powerpc/kvm/e500.h Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 09/16] KVM: PPC: e500: clean up arch/powerpc/kvm/e500.h Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 10/16] KVM: PPC: e500: refactor core-specific TLB code Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 11/16] KVM: PPC: e500: Track TLB1 entries with a bitmap Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 12/16] KVM: PPC: e500: emulate tlbilx Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 16:23 ` Alexander Graf
2012-01-09 16:23 ` Alexander Graf
2012-01-09 16:23 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 13/16] powerpc/booke: Provide exception macros with Scott Wood
2011-12-21 1:34 ` [RFC PATCH 13/16] powerpc/booke: Provide exception macros with interrupt name Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-02-17 8:50 ` Benjamin Herrenschmidt
2012-02-17 8:50 ` Benjamin Herrenschmidt
2012-02-17 8:50 ` Benjamin Herrenschmidt
2011-12-21 1:34 ` [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 17:46 ` Alexander Graf
2012-01-09 17:46 ` Alexander Graf
2012-01-09 17:46 ` Alexander Graf
2012-01-10 0:51 ` Scott Wood
2012-01-10 0:51 ` Scott Wood
2012-01-10 0:51 ` Scott Wood
2012-01-10 3:11 ` Alexander Graf
2012-01-10 3:11 ` Alexander Graf
2012-01-10 3:11 ` Alexander Graf
2012-01-10 22:03 ` Scott Wood
2012-01-10 22:03 ` Scott Wood
2012-01-10 22:03 ` Scott Wood
2012-01-10 23:06 ` Alexander Graf
2012-01-10 23:06 ` Alexander Graf
2012-01-10 23:06 ` Alexander Graf
2012-01-12 6:44 ` Benjamin Herrenschmidt
2012-01-12 6:44 ` Benjamin Herrenschmidt
2012-01-12 6:44 ` Benjamin Herrenschmidt
2012-01-12 7:11 ` Alexander Graf
2012-01-12 7:11 ` Alexander Graf
2012-01-12 7:11 ` Alexander Graf
2012-01-12 16:26 ` Scott Wood
2012-01-12 16:26 ` Scott Wood
2012-01-12 16:26 ` Scott Wood
2012-02-15 19:36 ` Alexander Graf
2012-02-15 19:36 ` Alexander Graf
2012-02-15 19:36 ` Alexander Graf
2012-02-15 19:40 ` Scott Wood
2012-02-15 19:40 ` Scott Wood
2012-02-15 19:40 ` Scott Wood
2012-02-15 23:18 ` Alexander Graf
2012-02-15 23:18 ` Alexander Graf
2012-02-15 23:18 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point Scott Wood
2011-12-21 1:34 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 17:48 ` Alexander Graf
2012-01-09 17:48 ` Alexander Graf
2012-01-09 17:48 ` Alexander Graf
2012-01-09 21:48 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point Scott Wood
2012-01-09 21:48 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support Scott Wood
2012-01-09 21:48 ` Scott Wood
2012-01-09 22:17 ` Alexander Graf
2012-01-09 22:17 ` Alexander Graf
2012-01-09 22:17 ` Alexander Graf
2012-01-09 22:39 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point Scott Wood
2012-01-09 22:39 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support Scott Wood
2012-01-09 22:39 ` Scott Wood
2012-01-09 22:47 ` Alexander Graf
2012-01-09 22:47 ` Alexander Graf
2012-01-09 22:47 ` Alexander Graf
2012-01-09 22:54 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point Scott Wood
2012-01-09 22:54 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support Scott Wood
2012-01-09 22:54 ` Scott Wood
2012-01-09 22:56 ` Alexander Graf
2012-01-09 22:56 ` Alexander Graf
2012-01-09 22:56 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 16/16] KVM: PPC: e500mc support Scott Wood
2011-12-21 1:34 ` Scott Wood
2011-12-21 1:34 ` Scott Wood
2012-01-09 16:33 ` Avi Kivity
2012-01-09 16:33 ` Avi Kivity
2012-01-09 16:33 ` Avi Kivity
2012-01-09 19:29 ` Scott Wood
2012-01-09 19:29 ` Scott Wood
2012-01-09 19:29 ` Scott Wood
2012-01-10 8:37 ` Avi Kivity
2012-01-10 8:37 ` Avi Kivity
2012-01-10 8:37 ` Avi Kivity
2012-01-10 22:20 ` Scott Wood [this message]
2012-01-10 22:20 ` Scott Wood
2012-01-10 22:20 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0CB9B7.9020607@freescale.com \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=varun.sethi@freescale.com \
--cc=yu.liu@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.