Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
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. Please read the DCO at https://lwn.net/Articles/437739/. It's okay to miss them from time to time, especially for established contributors, but avoid it whenever possible. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
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 [scottw...@freescale.com: significant rework] after them, or list them separately as part of the based on... paragraph. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
On 12/21/2011 03:34 AM, Scott Wood wrote: Add processor support for e500mc, using hardware virtualization support (GS-mode). Current issues include: - No support for external proxy (coreint) interrupt mode in the guest. Includes work by Ashish Kalra ashish.ka...@freescale.com, Varun Sethi varun.se...@freescale.com, and Liu Yu yu@freescale.com. Best to include their signoffs, if possible. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
On 01/09/2012 10:33 AM, Avi Kivity wrote: On 12/21/2011 03:34 AM, Scott Wood wrote: Add processor support for e500mc, using hardware virtualization support (GS-mode). Current issues include: - No support for external proxy (coreint) interrupt mode in the guest. Includes work by Ashish Kalra ashish.ka...@freescale.com, Varun Sethi varun.se...@freescale.com, and Liu Yu yu@freescale.com. 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. I've CCed Varun and Liu so they can sign off these versions of the patches if they wish. Ashish no longer works at Freescale, so I don't have a currently valid e-mail address for him. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev