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
next prev parent reply other threads:[~2020-02-24 10:54 UTC|newest]
Thread overview: 30+ 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 ` [RFC PATCH v2 01/12] powerpc: move ptrace into a subdirectory Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 02/12] powerpc/ptrace: drop unnecessary #ifdefs CONFIG_PPC64 Christophe Leroy
2019-06-28 16:36 ` Andreas Schwab
2019-06-28 16:39 ` Christophe Leroy
2019-06-28 17:08 ` Andreas Schwab
2020-02-24 10:48 ` Michael Ellerman
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 ` [RFC PATCH v2 04/12] powerpc/ptrace: split out VSX related functions Christophe Leroy
2020-02-24 10:51 ` Michael Ellerman
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 ` [RFC PATCH v2 06/12] powerpc/ptrace: split out SPE " 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 ` [RFC PATCH v2 08/12] powerpc/ptrace: move register viewing functions out of ptrace.c Christophe Leroy
2019-06-28 15:47 ` [RFC PATCH v2 09/12] powerpc/ptrace: split out ADV_DEBUG_REGS related functions Christophe Leroy
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-07-03 3:03 ` Ravi Bangoria
2019-06-28 15:48 ` [RFC PATCH v2 11/12] powerpc/ptrace: create ppc_gethwdinfo() Christophe Leroy
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-07-03 3:05 ` Ravi Bangoria
2019-07-03 6:29 ` [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace Ravi Bangoria
2020-02-17 6:49 ` Christophe Leroy
2020-02-24 2:15 ` Michael Neuling
2020-02-24 5:58 ` Christophe Leroy
2020-02-24 10:54 ` Michael Ellerman [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox