From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
naveen.n.rao@linux.vnet.ibm.com, jniethe5@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/12] powerpc: Cleanup use of 'struct ppc_inst'
Date: Wed, 16 Jun 2021 23:05:46 +1000 [thread overview]
Message-ID: <87eed2rmc5.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <0c2b2eb4-f58d-9ec3-4b98-af22cef188e2@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 15/06/2021 à 09:18, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> This series is a cleanup of the use of 'struct ppc_inst'.
>>>
>>> A confusion is made between internal representation of powerpc
>>> instructions with 'struct ppc_inst' and in-memory code which is
>>> and will always be an array of 'unsigned int'.
>>
>> Why don't we use u32 *, to make it even more explicit what the expected
>> size is?
>>
>
> I guess that's historical, we could use u32 *
Yeah I think it is historical, we just never thought about it much.
> We can convert it incrementaly maybe ?
I've still got this series in next-test, so I'll go through it and
change any uses of unsigned int * to u32 *, and then we can do another
pass later to change the remaining cases.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
naveen.n.rao@linux.vnet.ibm.com, jniethe5@gmail.com
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 00/12] powerpc: Cleanup use of 'struct ppc_inst'
Date: Wed, 16 Jun 2021 23:05:46 +1000 [thread overview]
Message-ID: <87eed2rmc5.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <0c2b2eb4-f58d-9ec3-4b98-af22cef188e2@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 15/06/2021 à 09:18, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> This series is a cleanup of the use of 'struct ppc_inst'.
>>>
>>> A confusion is made between internal representation of powerpc
>>> instructions with 'struct ppc_inst' and in-memory code which is
>>> and will always be an array of 'unsigned int'.
>>
>> Why don't we use u32 *, to make it even more explicit what the expected
>> size is?
>>
>
> I guess that's historical, we could use u32 *
Yeah I think it is historical, we just never thought about it much.
> We can convert it incrementaly maybe ?
I've still got this series in next-test, so I'll go through it and
change any uses of unsigned int * to u32 *, and then we can do another
pass later to change the remaining cases.
cheers
next prev parent reply other threads:[~2021-06-16 13:06 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 13:50 [PATCH v2 00/12] powerpc: Cleanup use of 'struct ppc_inst' Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 01/12] powerpc/inst: Fix sparse detection on get_user_instr() Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 02/12] powerpc/inst: Reduce casts in get_user_instr() Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 03/12] powerpc/inst: Improve readability of get_user_instr() and friends Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 04/12] powerpc/inst: Avoid pointer dereferencing in ppc_inst_equal() Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 3:38 ` Jordan Niethe
2021-06-15 3:38 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 05/12] powerpc: Do not dereference code as 'struct ppc_inst' (uprobe, code-patching, feature-fixups) Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 3:41 ` Jordan Niethe
2021-06-15 3:41 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 06/12] powerpc/lib/code-patching: Make instr_is_branch_to_addr() static Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 3:42 ` Jordan Niethe
2021-06-15 3:42 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 07/12] powerpc/lib/code-patching: Don't use struct 'ppc_inst' for runnable code in tests Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 3:42 ` Jordan Niethe
2021-06-15 3:42 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 08/12] powerpc: Don't use 'struct ppc_inst' to reference instruction location Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 2:01 ` Michael Ellerman
2021-06-15 2:01 ` Michael Ellerman
2021-06-15 3:47 ` Jordan Niethe
2021-06-15 3:47 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 09/12] powerpc/inst: Refactor PPC32 and PPC64 versions Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-15 3:48 ` Jordan Niethe
2021-06-15 3:48 ` Jordan Niethe
2021-05-20 13:50 ` [PATCH v2 10/12] powerpc/optprobes: Minimise casts Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 11/12] powerpc/optprobes: Compact code source a bit Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-05-20 13:50 ` [PATCH v2 12/12] powerpc/optprobes: use PPC_RAW_ macros Christophe Leroy
2021-05-20 13:50 ` Christophe Leroy
2021-06-08 12:46 ` [PATCH v2 00/12] powerpc: Cleanup use of 'struct ppc_inst' Christophe Leroy
2021-06-08 12:46 ` Christophe Leroy
2021-06-15 7:18 ` Michael Ellerman
2021-06-15 7:18 ` Michael Ellerman
2021-06-15 7:24 ` Christophe Leroy
2021-06-15 7:24 ` Christophe Leroy
2021-06-16 13:05 ` Michael Ellerman [this message]
2021-06-16 13:05 ` Michael Ellerman
2021-06-18 3:51 ` Michael Ellerman
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=87eed2rmc5.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jniethe5@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--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.