All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Thierry <jthierry@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	will@kernel.org, broonie@kernel.org
Subject: Re: [RFC PATCH 1/5] arm64: Move instruction encoder/decoder under lib/
Date: Wed, 3 Feb 2021 18:30:56 +0100	[thread overview]
Message-ID: <75b53229-f518-09f1-2449-ecac2352663c@redhat.com> (raw)
In-Reply-To: <20210203111240.GB55896@C02TD0UTHF1T.local>



On 2/3/21 12:12 PM, Mark Rutland wrote:
> On Wed, Feb 03, 2021 at 09:26:45AM +0100, Julien Thierry wrote:
>> On 2/2/21 11:17 AM, Mark Rutland wrote:
>>> On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
>>>> Aarch64 instruction set encoding and decoding logic can prove useful
>>>> for some features/tools both part of the kernel and outside the kernel.
>>>>
>>>> Isolate the function dealing only with encoding/decoding instructions,
>>>> with minimal dependency on kernel utilities in order to be able to reuse
>>>> that code.
>>>>
>>>> Code was only moved, no code should have been added, removed nor
>>>> modifier.
>>>>
>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com>
>>>
>>> This looks sound, but the diff is a little hard to check.
>>
>> Yes, I was expecting this change to be hard to digest.
>>
>>> Would it be possible to split this into two patches, where:
>>>
>>> 1) Refactoring definitions into insn.h and insn.c, leaving those files
>>>      in their current locations.
>>
>> I'm not quite sure I understand the suggestions. After this patch insn.h and
>> insn.c still contain some definitions that can't really be used outside of
>> kernel code which is why I split them into insn.* and aarch64-insn.* (the
>> latter containing what could be used by tools).
> 
> Sorry; I hadn't appreciated what was getting left behind. With the
> series applied I see that's some kernel patching logic, and AArch32 insn
> bits.
> 
> How about we invert the move, and split those bits out of insn.c first,
> then move the rest in one go, i.e.
> 
> 1) Factor the patching bits out into new patching.{c,h} files.
> 
> 2) Move insn.c to arch/arm64/lib/
> 
> 3) Split insn.* into aarch64-insn.* and aarch32-insn.*
> 
> ... if that makes any sense?
> 
> We might not even need to split the aarch32 bits out given they all have
> an aarch32_* prefix.
> 

Yes, that approach sounds good. I'll if the aarchxx-insn is necessary 
but as you say, all in the same file shouldn't cause trouble.

Thanks,

-- 
Julien Thierry


WARNING: multiple messages have this Message-ID (diff)
From: Julien Thierry <jthierry@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, broonie@kernel.org, will@kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/5] arm64: Move instruction encoder/decoder under lib/
Date: Wed, 3 Feb 2021 18:30:56 +0100	[thread overview]
Message-ID: <75b53229-f518-09f1-2449-ecac2352663c@redhat.com> (raw)
In-Reply-To: <20210203111240.GB55896@C02TD0UTHF1T.local>



On 2/3/21 12:12 PM, Mark Rutland wrote:
> On Wed, Feb 03, 2021 at 09:26:45AM +0100, Julien Thierry wrote:
>> On 2/2/21 11:17 AM, Mark Rutland wrote:
>>> On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
>>>> Aarch64 instruction set encoding and decoding logic can prove useful
>>>> for some features/tools both part of the kernel and outside the kernel.
>>>>
>>>> Isolate the function dealing only with encoding/decoding instructions,
>>>> with minimal dependency on kernel utilities in order to be able to reuse
>>>> that code.
>>>>
>>>> Code was only moved, no code should have been added, removed nor
>>>> modifier.
>>>>
>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com>
>>>
>>> This looks sound, but the diff is a little hard to check.
>>
>> Yes, I was expecting this change to be hard to digest.
>>
>>> Would it be possible to split this into two patches, where:
>>>
>>> 1) Refactoring definitions into insn.h and insn.c, leaving those files
>>>      in their current locations.
>>
>> I'm not quite sure I understand the suggestions. After this patch insn.h and
>> insn.c still contain some definitions that can't really be used outside of
>> kernel code which is why I split them into insn.* and aarch64-insn.* (the
>> latter containing what could be used by tools).
> 
> Sorry; I hadn't appreciated what was getting left behind. With the
> series applied I see that's some kernel patching logic, and AArch32 insn
> bits.
> 
> How about we invert the move, and split those bits out of insn.c first,
> then move the rest in one go, i.e.
> 
> 1) Factor the patching bits out into new patching.{c,h} files.
> 
> 2) Move insn.c to arch/arm64/lib/
> 
> 3) Split insn.* into aarch64-insn.* and aarch32-insn.*
> 
> ... if that makes any sense?
> 
> We might not even need to split the aarch32 bits out given they all have
> an aarch32_* prefix.
> 

Yes, that approach sounds good. I'll if the aarchxx-insn is necessary 
but as you say, all in the same file shouldn't cause trouble.

Thanks,

-- 
Julien Thierry


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-02-03 17:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 17:17 [RFC PATCH 0/5] arm64: Prepare instruction decoder for objtool Julien Thierry
2021-01-20 17:17 ` Julien Thierry
2021-01-20 17:17 ` [RFC PATCH 1/5] arm64: Move instruction encoder/decoder under lib/ Julien Thierry
2021-02-02 10:17   ` Mark Rutland
2021-02-03  8:26     ` Julien Thierry
2021-02-03  8:26       ` Julien Thierry
2021-02-03 11:12       ` Mark Rutland
2021-02-03 11:12         ` Mark Rutland
2021-02-03 17:30         ` Julien Thierry [this message]
2021-02-03 17:30           ` Julien Thierry
2021-01-20 17:17 ` [RFC PATCH 2/5] arm64: aarch64-insn: Add SVE instruction class Julien Thierry
2021-01-20 17:17   ` Julien Thierry
2021-01-20 17:17 ` [RFC PATCH 3/5] arm64: aarch64-insn: Add barrier encodings Julien Thierry
2021-01-20 17:17   ` Julien Thierry
2021-02-02 11:15   ` Mark Rutland
2021-02-02 11:15     ` Mark Rutland
2021-02-03  8:47     ` Julien Thierry
2021-02-03  8:47       ` Julien Thierry
2021-01-20 17:17 ` [RFC PATCH 4/5] arm64: aarch64-insn: Add some opcodes to instruction decoder Julien Thierry
2021-01-20 17:17   ` Julien Thierry
2021-01-20 17:17 ` [RFC PATCH 5/5] arm64: Add load/store decoding helpers Julien Thierry
2021-01-20 17:17   ` Julien Thierry

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=75b53229-f518-09f1-2449-ecac2352663c@redhat.com \
    --to=jthierry@redhat.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=will@kernel.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.