From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@c-s.fr>,
Michael Neuling <mikey@neuling.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace
Date: Mon, 24 Feb 2020 21:54:00 +1100 [thread overview]
Message-ID: <8736b01cjb.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <5b5d8f61-c9aa-1afd-6001-44a17f00c1a6@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Le 24/02/2020 à 03:15, Michael Neuling a écrit :
>> Christophe,
>>> Le 28/06/2019 à 17:47, Christophe Leroy a écrit :
>>>> The purpose of this series is to reduce the amount of #ifdefs
>>>> in ptrace.c
>>>
>>> Any feedback on this series which aims at fixing the issue you opened at
>>> https://github.com/linuxppc/issues/issues/128 ?
>>
>> Yeah, sorry my bad. You did all the hard work and I ignored it.
>>
>> I like the approach and is a long the lines I was thinking. Putting it in a
>> ptrace subdir, splitting out adv_debug_regs, TM, SPE, Alitivec, VSX.
>> ppc_gethwdinfo() looks a lot nicer now too (that was some of the worst of it).
>>
>> I've not gone through it with a fine tooth comb though. There is (rightly) a lot
>> of code moved around which could have introduced some issues.
>>
>> It applies on v5.2 but are you planning on updating it to a newer base?
>>
>
> As you noticed there is a lot of code moved around, and rebasing
> produces a lot of conflicts. So I didn't want to spend hours to rebase
> and rebase without being sure it was the right approach.
>
> Now that I got a positive feedback I'll consider rebasing it, hopping
> that Michael will pick it up.
I would love to.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@c-s.fr>,
Michael Neuling <mikey@neuling.org>
Cc: Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace
Date: Mon, 24 Feb 2020 21:54:00 +1100 [thread overview]
Message-ID: <8736b01cjb.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <5b5d8f61-c9aa-1afd-6001-44a17f00c1a6@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Le 24/02/2020 à 03:15, Michael Neuling a écrit :
>> Christophe,
>>> Le 28/06/2019 à 17:47, Christophe Leroy a écrit :
>>>> The purpose of this series is to reduce the amount of #ifdefs
>>>> in ptrace.c
>>>
>>> Any feedback on this series which aims at fixing the issue you opened at
>>> https://github.com/linuxppc/issues/issues/128 ?
>>
>> Yeah, sorry my bad. You did all the hard work and I ignored it.
>>
>> I like the approach and is a long the lines I was thinking. Putting it in a
>> ptrace subdir, splitting out adv_debug_regs, TM, SPE, Alitivec, VSX.
>> ppc_gethwdinfo() looks a lot nicer now too (that was some of the worst of it).
>>
>> I've not gone through it with a fine tooth comb though. There is (rightly) a lot
>> of code moved around which could have introduced some issues.
>>
>> It applies on v5.2 but are you planning on updating it to a newer base?
>>
>
> As you noticed there is a lot of code moved around, and rebasing
> produces a lot of conflicts. So I didn't want to spend hours to rebase
> and rebase without being sure it was the right approach.
>
> Now that I got a positive feedback I'll consider rebasing it, hopping
> that Michael will pick it up.
I would love to.
cheers
next prev parent reply other threads:[~2020-02-24 10:54 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 15:47 [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 01/12] powerpc: move ptrace into a subdirectory Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 02/12] powerpc/ptrace: drop unnecessary #ifdefs CONFIG_PPC64 Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 16:36 ` Andreas Schwab
2019-06-28 16:36 ` Andreas Schwab
2019-06-28 16:39 ` Christophe Leroy
2019-06-28 16:39 ` Christophe Leroy
2019-06-28 17:08 ` Andreas Schwab
2019-06-28 17:08 ` Andreas Schwab
2020-02-24 10:48 ` Michael Ellerman
2020-02-24 10:48 ` Michael Ellerman
2020-02-26 12:06 ` Christophe Leroy
2020-02-26 12:06 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 03/12] powerpc/ptrace: drop PARAMETER_SAVE_AREA_OFFSET Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 04/12] powerpc/ptrace: split out VSX related functions Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2020-02-24 10:51 ` Michael Ellerman
2020-02-24 10:51 ` Michael Ellerman
2020-02-26 12:04 ` Christophe Leroy
2020-02-26 12:04 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 05/12] powerpc/ptrace: split out ALTIVEC " Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 06/12] powerpc/ptrace: split out SPE " Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 07/12] powerpc/ptrace: split out TRANSACTIONAL_MEM " Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 08/12] powerpc/ptrace: move register viewing functions out of ptrace.c Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 09/12] powerpc/ptrace: split out ADV_DEBUG_REGS related functions Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-07-03 2:52 ` Ravi Bangoria
2019-07-03 2:52 ` Ravi Bangoria
2019-06-28 15:47 ` [RFC PATCH v2 10/12] powerpc/ptrace: create ptrace_get_debugreg() Christophe Leroy
2019-06-28 15:47 ` Christophe Leroy
2019-07-03 3:03 ` Ravi Bangoria
2019-07-03 3:03 ` Ravi Bangoria
2019-06-28 15:48 ` [RFC PATCH v2 11/12] powerpc/ptrace: create ppc_gethwdinfo() Christophe Leroy
2019-06-28 15:48 ` Christophe Leroy
2019-07-03 3:18 ` Ravi Bangoria
2019-07-03 3:18 ` Ravi Bangoria
2019-06-28 15:48 ` [RFC PATCH v2 12/12] powerpc/ptrace: move ptrace_triggered() into hw_breakpoint.c Christophe Leroy
2019-06-28 15:48 ` Christophe Leroy
2019-07-03 3:05 ` Ravi Bangoria
2019-07-03 3:05 ` Ravi Bangoria
2019-07-03 6:29 ` [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace Ravi Bangoria
2019-07-03 6:29 ` Ravi Bangoria
2020-02-17 6:49 ` Christophe Leroy
2020-02-17 6:49 ` Christophe Leroy
2020-02-24 2:15 ` Michael Neuling
2020-02-24 2:15 ` Michael Neuling
2020-02-24 5:58 ` Christophe Leroy
2020-02-24 5:58 ` Christophe Leroy
2020-02-24 10:54 ` Michael Ellerman [this message]
2020-02-24 10:54 ` Michael Ellerman
2020-02-26 12:03 ` Christophe Leroy
2020-02-26 12:03 ` Christophe Leroy
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=8736b01cjb.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=paulus@samba.org \
/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.