All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Long <dave.long@linaro.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Rob Herring <robherring2@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Anton Blanchard <anton@samba.org>,
	Behan Webster <behanw@converseincode.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Eric Paris <eparis@redhat.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Willeke <willeke@de.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Nikolay Borisov <Nikolay.Borisov@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Richard Kuo <rkuo@codeaurora.org>,
	Robert Richter <rric@kernel.org>,
	Roland McGrath <roland@hack.frob.com>,
	Russell King <linux@arm.linux.org.uk>, Tejun Heo <tj@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will.deacon@arm.com>,
	"linux-arm-kernel@lists.infradead.org" <linux-arm-ker>
Subject: Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
Date: Wed, 22 Jul 2015 09:30:59 -0400	[thread overview]
Message-ID: <55AF9B13.4010406@linaro.org> (raw)
In-Reply-To: <1437541889.16792.11.camel@ellerman.id.au>

On 07/22/15 01:11, Michael Ellerman wrote:
> On Wed, 2015-07-22 at 00:46 -0400, David Long wrote:
>> On 06/29/15 23:29, Michael Ellerman wrote:
>>> On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
>>>> On 06/16/15 09:17, Rob Herring wrote:
>>>>> On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@linaro.org> wrote:
>>>>>>
>>>>>>     #define REG_OFFSET_NAME(r) \
>>>>>>            {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>>>>>>     #define REG_OFFSET_END {.name = NULL, .offset = 0}
>>>>>
>>>>> Can't you also move these? ARM is complicated with the "ARM_"
>>>>> prefixing, but the others appear to be the same. Maybe you can remove
>>>>> the prefix or redefine the macro for ARM.
>>>>
>>>> That would mandate that all the architecture-specific pt_regs structures
>>>> would have to use a top-level named field for each named register.
>>>
>>> Why does it mandate that?
>>>
>>> See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
>>> then a different macro for the array elements:
>>>
>>>     #define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
>>>     #define GPR_OFFSET_NAME(num)	\
>>>     	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
>>>
>>>     static const struct pt_regs_offset regoffset_table[] = {
>>>     	GPR_OFFSET_NAME(0),
>>>     	GPR_OFFSET_NAME(1),
>>>     	GPR_OFFSET_NAME(2),
>>>     	GPR_OFFSET_NAME(3),
>>>     	...
>>>     	REG_OFFSET_NAME(nip),
>>>     	REG_OFFSET_NAME(msr),
>>>
>>>
>>> So I don't see why REG_OFFSET_NAME couldn't be common.
>>>
>>
>> Sorry for the delay in responding to this.
>>
>> OK, so you're saying architectures that don't want this constraint can
>> make their own macro.  Seems to make this whole exercise slightly less
>> useful, but whatever.
>
> Well yeah.
>
> In fact of the 4 arches that use REG_OFFSET_NAME, 2 already have another macro
> for specially named registers (powerpc & sh).
>
>> I see three ways to go here:
>>
>> 1) Leave it as is.
>> 2) Force all architectures to use a common definition.
>> 3) Provide a common definition that all architectures (except "arm")
>> currently using this functionality will use.
>>
>> I have a v2 patch to implement #3, ready to post.  Do we think this is
>> the way to go?
>
> Yeah I think it is. How are you making it conditional? Just #ifndef REG_OFFSET_NAME?
>

I'm just defining a new macro for arm.  The macro is only invoked in one 
arm file.  Then the REG_OFFSET_NAME macro goes unused for this architecture.

>> I don't like #2 because I really don't want to rename all
>> uses of the current register fields for arm since this is
>> architecture-specific code to begin with and since it affects code in 39
>> arm source files.
>
> I guess you're talking about renaming all the ARM_x regs to x. That would
> likely cause problems because they're implemented as #defines,
> eg. #define r0 uregs[0] would probably confuse your assembler.
>

Yeah, and I had not looked further to the implications of doing that but 
I see you've found where it is a genuine problem.

> The clean thing to do would be to have the in-kernel struct pt_regs have actual
> named members, but that would still be an intrusive change.
>
> cheers
>
>

Thanks,
-dl

WARNING: multiple messages have this Message-ID (diff)
From: David Long <dave.long@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
Date: Wed, 22 Jul 2015 13:30:59 +0000	[thread overview]
Message-ID: <55AF9B13.4010406@linaro.org> (raw)
In-Reply-To: <1437541889.16792.11.camel@ellerman.id.au>

On 07/22/15 01:11, Michael Ellerman wrote:
> On Wed, 2015-07-22 at 00:46 -0400, David Long wrote:
>> On 06/29/15 23:29, Michael Ellerman wrote:
>>> On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
>>>> On 06/16/15 09:17, Rob Herring wrote:
>>>>> On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@linaro.org> wrote:
>>>>>>
>>>>>>     #define REG_OFFSET_NAME(r) \
>>>>>>            {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>>>>>>     #define REG_OFFSET_END {.name = NULL, .offset = 0}
>>>>>
>>>>> Can't you also move these? ARM is complicated with the "ARM_"
>>>>> prefixing, but the others appear to be the same. Maybe you can remove
>>>>> the prefix or redefine the macro for ARM.
>>>>
>>>> That would mandate that all the architecture-specific pt_regs structures
>>>> would have to use a top-level named field for each named register.
>>>
>>> Why does it mandate that?
>>>
>>> See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
>>> then a different macro for the array elements:
>>>
>>>     #define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
>>>     #define GPR_OFFSET_NAME(num)	\
>>>     	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
>>>
>>>     static const struct pt_regs_offset regoffset_table[] = {
>>>     	GPR_OFFSET_NAME(0),
>>>     	GPR_OFFSET_NAME(1),
>>>     	GPR_OFFSET_NAME(2),
>>>     	GPR_OFFSET_NAME(3),
>>>     	...
>>>     	REG_OFFSET_NAME(nip),
>>>     	REG_OFFSET_NAME(msr),
>>>
>>>
>>> So I don't see why REG_OFFSET_NAME couldn't be common.
>>>
>>
>> Sorry for the delay in responding to this.
>>
>> OK, so you're saying architectures that don't want this constraint can
>> make their own macro.  Seems to make this whole exercise slightly less
>> useful, but whatever.
>
> Well yeah.
>
> In fact of the 4 arches that use REG_OFFSET_NAME, 2 already have another macro
> for specially named registers (powerpc & sh).
>
>> I see three ways to go here:
>>
>> 1) Leave it as is.
>> 2) Force all architectures to use a common definition.
>> 3) Provide a common definition that all architectures (except "arm")
>> currently using this functionality will use.
>>
>> I have a v2 patch to implement #3, ready to post.  Do we think this is
>> the way to go?
>
> Yeah I think it is. How are you making it conditional? Just #ifndef REG_OFFSET_NAME?
>

I'm just defining a new macro for arm.  The macro is only invoked in one 
arm file.  Then the REG_OFFSET_NAME macro goes unused for this architecture.

>> I don't like #2 because I really don't want to rename all
>> uses of the current register fields for arm since this is
>> architecture-specific code to begin with and since it affects code in 39
>> arm source files.
>
> I guess you're talking about renaming all the ARM_x regs to x. That would
> likely cause problems because they're implemented as #defines,
> eg. #define r0 uregs[0] would probably confuse your assembler.
>

Yeah, and I had not looked further to the implications of doing that but 
I see you've found where it is a genuine problem.

> The clean thing to do would be to have the in-kernel struct pt_regs have actual
> named members, but that would still be an intrusive change.
>
> cheers
>
>

Thanks,
-dl


WARNING: multiple messages have this Message-ID (diff)
From: David Long <dave.long@linaro.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Rob Herring <robherring2@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Anton Blanchard <anton@samba.org>,
	Behan Webster <behanw@converseincode.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Eric Paris <eparis@redhat.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Willeke <willeke@de.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Nikolay Borisov <Nikolay.Borisov@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Richard Kuo <rkuo@codeaurora.org>,
	Robert Richter <rric@kernel.org>,
	Roland McGrath <roland@hack.frob.com>,
	Russell King <linux@arm.linux.org.uk>, Tejun Heo <tj@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will.deacon@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-hexagon@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-s390@vger.kernel.org, SH-Linux <linux-sh@vger.kernel.org>,
	linux390@de.ibm.com, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
Date: Wed, 22 Jul 2015 09:30:59 -0400	[thread overview]
Message-ID: <55AF9B13.4010406@linaro.org> (raw)
In-Reply-To: <1437541889.16792.11.camel@ellerman.id.au>

On 07/22/15 01:11, Michael Ellerman wrote:
> On Wed, 2015-07-22 at 00:46 -0400, David Long wrote:
>> On 06/29/15 23:29, Michael Ellerman wrote:
>>> On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
>>>> On 06/16/15 09:17, Rob Herring wrote:
>>>>> On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@linaro.org> wrote:
>>>>>>
>>>>>>     #define REG_OFFSET_NAME(r) \
>>>>>>            {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>>>>>>     #define REG_OFFSET_END {.name = NULL, .offset = 0}
>>>>>
>>>>> Can't you also move these? ARM is complicated with the "ARM_"
>>>>> prefixing, but the others appear to be the same. Maybe you can remove
>>>>> the prefix or redefine the macro for ARM.
>>>>
>>>> That would mandate that all the architecture-specific pt_regs structures
>>>> would have to use a top-level named field for each named register.
>>>
>>> Why does it mandate that?
>>>
>>> See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
>>> then a different macro for the array elements:
>>>
>>>     #define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
>>>     #define GPR_OFFSET_NAME(num)	\
>>>     	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
>>>
>>>     static const struct pt_regs_offset regoffset_table[] = {
>>>     	GPR_OFFSET_NAME(0),
>>>     	GPR_OFFSET_NAME(1),
>>>     	GPR_OFFSET_NAME(2),
>>>     	GPR_OFFSET_NAME(3),
>>>     	...
>>>     	REG_OFFSET_NAME(nip),
>>>     	REG_OFFSET_NAME(msr),
>>>
>>>
>>> So I don't see why REG_OFFSET_NAME couldn't be common.
>>>
>>
>> Sorry for the delay in responding to this.
>>
>> OK, so you're saying architectures that don't want this constraint can
>> make their own macro.  Seems to make this whole exercise slightly less
>> useful, but whatever.
>
> Well yeah.
>
> In fact of the 4 arches that use REG_OFFSET_NAME, 2 already have another macro
> for specially named registers (powerpc & sh).
>
>> I see three ways to go here:
>>
>> 1) Leave it as is.
>> 2) Force all architectures to use a common definition.
>> 3) Provide a common definition that all architectures (except "arm")
>> currently using this functionality will use.
>>
>> I have a v2 patch to implement #3, ready to post.  Do we think this is
>> the way to go?
>
> Yeah I think it is. How are you making it conditional? Just #ifndef REG_OFFSET_NAME?
>

I'm just defining a new macro for arm.  The macro is only invoked in one 
arm file.  Then the REG_OFFSET_NAME macro goes unused for this architecture.

>> I don't like #2 because I really don't want to rename all
>> uses of the current register fields for arm since this is
>> architecture-specific code to begin with and since it affects code in 39
>> arm source files.
>
> I guess you're talking about renaming all the ARM_x regs to x. That would
> likely cause problems because they're implemented as #defines,
> eg. #define r0 uregs[0] would probably confuse your assembler.
>

Yeah, and I had not looked further to the implications of doing that but 
I see you've found where it is a genuine problem.

> The clean thing to do would be to have the in-kernel struct pt_regs have actual
> named members, but that would still be an intrusive change.
>
> cheers
>
>

Thanks,
-dl

WARNING: multiple messages have this Message-ID (diff)
From: dave.long@linaro.org (David Long)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
Date: Wed, 22 Jul 2015 09:30:59 -0400	[thread overview]
Message-ID: <55AF9B13.4010406@linaro.org> (raw)
In-Reply-To: <1437541889.16792.11.camel@ellerman.id.au>

On 07/22/15 01:11, Michael Ellerman wrote:
> On Wed, 2015-07-22 at 00:46 -0400, David Long wrote:
>> On 06/29/15 23:29, Michael Ellerman wrote:
>>> On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
>>>> On 06/16/15 09:17, Rob Herring wrote:
>>>>> On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@linaro.org> wrote:
>>>>>>
>>>>>>     #define REG_OFFSET_NAME(r) \
>>>>>>            {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>>>>>>     #define REG_OFFSET_END {.name = NULL, .offset = 0}
>>>>>
>>>>> Can't you also move these? ARM is complicated with the "ARM_"
>>>>> prefixing, but the others appear to be the same. Maybe you can remove
>>>>> the prefix or redefine the macro for ARM.
>>>>
>>>> That would mandate that all the architecture-specific pt_regs structures
>>>> would have to use a top-level named field for each named register.
>>>
>>> Why does it mandate that?
>>>
>>> See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
>>> then a different macro for the array elements:
>>>
>>>     #define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
>>>     #define GPR_OFFSET_NAME(num)	\
>>>     	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
>>>
>>>     static const struct pt_regs_offset regoffset_table[] = {
>>>     	GPR_OFFSET_NAME(0),
>>>     	GPR_OFFSET_NAME(1),
>>>     	GPR_OFFSET_NAME(2),
>>>     	GPR_OFFSET_NAME(3),
>>>     	...
>>>     	REG_OFFSET_NAME(nip),
>>>     	REG_OFFSET_NAME(msr),
>>>
>>>
>>> So I don't see why REG_OFFSET_NAME couldn't be common.
>>>
>>
>> Sorry for the delay in responding to this.
>>
>> OK, so you're saying architectures that don't want this constraint can
>> make their own macro.  Seems to make this whole exercise slightly less
>> useful, but whatever.
>
> Well yeah.
>
> In fact of the 4 arches that use REG_OFFSET_NAME, 2 already have another macro
> for specially named registers (powerpc & sh).
>
>> I see three ways to go here:
>>
>> 1) Leave it as is.
>> 2) Force all architectures to use a common definition.
>> 3) Provide a common definition that all architectures (except "arm")
>> currently using this functionality will use.
>>
>> I have a v2 patch to implement #3, ready to post.  Do we think this is
>> the way to go?
>
> Yeah I think it is. How are you making it conditional? Just #ifndef REG_OFFSET_NAME?
>

I'm just defining a new macro for arm.  The macro is only invoked in one 
arm file.  Then the REG_OFFSET_NAME macro goes unused for this architecture.

>> I don't like #2 because I really don't want to rename all
>> uses of the current register fields for arm since this is
>> architecture-specific code to begin with and since it affects code in 39
>> arm source files.
>
> I guess you're talking about renaming all the ARM_x regs to x. That would
> likely cause problems because they're implemented as #defines,
> eg. #define r0 uregs[0] would probably confuse your assembler.
>

Yeah, and I had not looked further to the implications of doing that but 
I see you've found where it is a genuine problem.

> The clean thing to do would be to have the in-kernel struct pt_regs have actual
> named members, but that would still be an intrusive change.
>
> cheers
>
>

Thanks,
-dl

  reply	other threads:[~2015-07-22 13:30 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 16:42 [PATCH 0/2] Consolidate redundant register/stack access code David Long
2015-06-15 16:42 ` David Long
2015-06-15 16:42 ` David Long
2015-06-15 16:42 ` David Long
2015-06-15 16:42 ` [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file David Long
2015-06-15 16:42   ` David Long
2015-06-15 16:42   ` David Long
2015-06-15 16:42   ` David Long
2015-06-16 13:17   ` Rob Herring
2015-06-16 13:17     ` Rob Herring
2015-06-16 13:17     ` Rob Herring
2015-06-16 13:17     ` Rob Herring
2015-06-17 18:30     ` David Long
2015-06-17 18:30       ` David Long
2015-06-17 18:30       ` David Long
2015-06-17 18:30       ` David Long
2015-06-30  3:29       ` Michael Ellerman
2015-06-30  3:29         ` Michael Ellerman
2015-06-30  3:29         ` Michael Ellerman
2015-06-30  3:29         ` Michael Ellerman
2015-07-22  4:46         ` David Long
2015-07-22  4:46           ` David Long
2015-07-22  4:46           ` David Long
2015-07-22  4:46           ` David Long
2015-07-22  5:11           ` Michael Ellerman
2015-07-22  5:11             ` Michael Ellerman
2015-07-22  5:11             ` Michael Ellerman
2015-07-22  5:11             ` Michael Ellerman
2015-07-22 13:30             ` David Long [this message]
2015-07-22 13:30               ` David Long
2015-07-22 13:30               ` David Long
2015-07-22 13:30               ` David Long
2015-06-19  4:19   ` Michael Ellerman
2015-06-19  4:19     ` Michael Ellerman
2015-06-19  4:19     ` Michael Ellerman
2015-06-19  4:19     ` Michael Ellerman
2015-06-19 14:12     ` David Long
2015-06-19 14:12       ` David Long
2015-06-19 14:12       ` David Long
2015-06-19 14:12       ` David Long
2015-06-19 14:12       ` David Long
2015-06-19 16:58       ` Kees Cook
2015-06-19 16:58         ` Kees Cook
2015-06-19 16:58         ` Kees Cook
2015-06-19 16:58         ` Kees Cook
2015-06-19 16:58         ` Kees Cook
2015-06-26 18:35         ` David Long
2015-06-26 18:35           ` David Long
2015-06-26 18:35           ` David Long
2015-06-26 18:35           ` David Long
2015-06-23  3:32       ` Michael Ellerman
2015-06-23  3:32         ` Michael Ellerman
2015-06-23  3:32         ` Michael Ellerman
2015-06-23  3:32         ` Michael Ellerman
2015-06-23  3:32         ` Michael Ellerman
2015-06-23 13:48         ` David Long
2015-06-23 13:48           ` David Long
2015-06-23 13:48           ` David Long
2015-06-23 13:48           ` David Long
2015-06-24  4:07           ` Michael Ellerman
2015-06-24  4:07             ` Michael Ellerman
2015-06-24  4:07             ` Michael Ellerman
2015-06-24  4:07             ` Michael Ellerman
2015-06-24 13:49             ` David Long
2015-06-24 13:49               ` David Long
2015-06-24 13:49               ` David Long
2015-06-24 13:49               ` David Long
2015-06-15 16:42 ` [PATCH 2/2] Consolidate redundant register/stack access code David Long
2015-06-15 16:42   ` David Long
2015-06-15 16:42   ` David Long
2015-06-15 16:42   ` David Long
2015-06-18 18:13   ` rkuo
2015-06-18 18:13     ` rkuo
2015-06-18 18:13     ` rkuo
2015-06-18 18:13     ` rkuo
2015-06-15 20:44 ` [PATCH 0/2] " Kees Cook
2015-06-15 20:44   ` Kees Cook
2015-06-15 20:44   ` Kees Cook
2015-06-15 20:44   ` Kees Cook
2015-06-15 20:58   ` David Long
2015-06-15 20:58     ` David Long
2015-06-15 20:58     ` David Long
2015-06-15 20:58     ` David Long
2015-06-16  8:12 ` Martin Schwidefsky
2015-06-16  8:12   ` Martin Schwidefsky
2015-06-16  8:12   ` Martin Schwidefsky
2015-06-16  8:12   ` Martin Schwidefsky
2015-06-16 17:39 ` Will Deacon
2015-06-16 17:39   ` Will Deacon
2015-06-16 17:39   ` Will Deacon
2015-06-16 17:39   ` Will Deacon

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=55AF9B13.4010406@linaro.org \
    --to=dave.long@linaro.org \
    --cc=Nikolay.Borisov@arm.com \
    --cc=anton@samba.org \
    --cc=behanw@converseincode.com \
    --cc=benh@kernel.crashing.org \
    --cc=eparis@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --cc=rkuo@codeaurora.org \
    --cc=robherring2@gmail.com \
    --cc=roland@hack.frob.com \
    --cc=rric@kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=will.deacon@arm.com \
    --cc=willeke@de.ibm.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.