From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kernel-team@android.com,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu, Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables
Date: Fri, 24 Jan 2020 14:02:37 +0000 [thread overview]
Message-ID: <20200124140237.GA180536@google.com> (raw)
In-Reply-To: <af9e7292f723f808406510f437d5b0eb@kernel.org>
On Friday 24 Jan 2020 at 13:34:35 (+0000), Marc Zyngier wrote:
> I don't disagree at all. To be honest, I've been on the cusp of getting
> rid of it for a while, for multiple reasons:
>
> - It has no users (as you noticed)
> - It is hardly tested (a consequence of the above)
> - It isn't feature complete (no debug, no PMU)
> - It doesn't follow any of the evolution of the architecture (a more
> generic feature of the 32bit port, probably because people run their
> 64bit-capable cores in 64bit mode)
> - It is becoming a mess of empty stubs
>
> The maintenance aspect hasn't been a real problem so far. Even the NV
> support is only about 200 lines of stubs. But what you have in mind is
> going to be much more invasive, and I wouldn't want an unused feature to
> get in the way.
>
> What I may end-up doing is to send a RFC series to remove the 32bit host
> support from the tree during in the 5.6 cycle, targeting 5.7. If someone
> shouts loudly during that time frame, we keep it and you'll have to work
> around it. If nobody cares, then dropping it is the right thing to do.
>
> Would that be OK with you?
Absolutely. And yes, if there are users of the 32 bits port, it'll be on
us to work around in a clean way, but I think this is perfectly fair.
I'll be happy to try and test your RFC series when it goes on the list
if that can help.
Thanks!
Quentin
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kernel-team@android.com,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu, Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables
Date: Fri, 24 Jan 2020 14:02:37 +0000 [thread overview]
Message-ID: <20200124140237.GA180536@google.com> (raw)
In-Reply-To: <af9e7292f723f808406510f437d5b0eb@kernel.org>
On Friday 24 Jan 2020 at 13:34:35 (+0000), Marc Zyngier wrote:
> I don't disagree at all. To be honest, I've been on the cusp of getting
> rid of it for a while, for multiple reasons:
>
> - It has no users (as you noticed)
> - It is hardly tested (a consequence of the above)
> - It isn't feature complete (no debug, no PMU)
> - It doesn't follow any of the evolution of the architecture (a more
> generic feature of the 32bit port, probably because people run their
> 64bit-capable cores in 64bit mode)
> - It is becoming a mess of empty stubs
>
> The maintenance aspect hasn't been a real problem so far. Even the NV
> support is only about 200 lines of stubs. But what you have in mind is
> going to be much more invasive, and I wouldn't want an unused feature to
> get in the way.
>
> What I may end-up doing is to send a RFC series to remove the 32bit host
> support from the tree during in the 5.6 cycle, targeting 5.7. If someone
> shouts loudly during that time frame, we keep it and you'll have to work
> around it. If nobody cares, then dropping it is the right thing to do.
>
> Would that be OK with you?
Absolutely. And yes, if there are users of the 32 bits port, it'll be on
us to work around in a clean way, but I think this is perfectly fair.
I'll be happy to try and test your RFC series when it goes on the list
if that can help.
Thanks!
Quentin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>, Mike Rapoport <rppt@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org,
Mike Rapoport <rppt@linux.ibm.com>,
kvmarm@lists.cs.columbia.edu, kernel-team@android.com
Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables
Date: Fri, 24 Jan 2020 14:02:37 +0000 [thread overview]
Message-ID: <20200124140237.GA180536@google.com> (raw)
In-Reply-To: <af9e7292f723f808406510f437d5b0eb@kernel.org>
On Friday 24 Jan 2020 at 13:34:35 (+0000), Marc Zyngier wrote:
> I don't disagree at all. To be honest, I've been on the cusp of getting
> rid of it for a while, for multiple reasons:
>
> - It has no users (as you noticed)
> - It is hardly tested (a consequence of the above)
> - It isn't feature complete (no debug, no PMU)
> - It doesn't follow any of the evolution of the architecture (a more
> generic feature of the 32bit port, probably because people run their
> 64bit-capable cores in 64bit mode)
> - It is becoming a mess of empty stubs
>
> The maintenance aspect hasn't been a real problem so far. Even the NV
> support is only about 200 lines of stubs. But what you have in mind is
> going to be much more invasive, and I wouldn't want an unused feature to
> get in the way.
>
> What I may end-up doing is to send a RFC series to remove the 32bit host
> support from the tree during in the 5.6 cycle, targeting 5.7. If someone
> shouts loudly during that time frame, we keep it and you'll have to work
> around it. If nobody cares, then dropping it is the right thing to do.
>
> Would that be OK with you?
Absolutely. And yes, if there are users of the 32 bits port, it'll be on
us to work around in a clean way, but I think this is perfectly fair.
I'll be happy to try and test your RFC series when it goes on the list
if that can help.
Thanks!
Quentin
next prev parent reply other threads:[~2020-01-24 14:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 11:13 [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables Mike Rapoport
2020-01-13 11:13 ` Mike Rapoport
2020-01-13 11:13 ` Mike Rapoport
2020-01-13 11:13 ` [PATCH v2 1/1] " Mike Rapoport
2020-01-13 11:13 ` Mike Rapoport
2020-01-13 11:13 ` Mike Rapoport
2020-01-22 18:50 ` [PATCH v2 0/1] " Will Deacon
2020-01-22 18:50 ` Will Deacon
2020-01-22 18:50 ` Will Deacon
2020-01-22 18:56 ` Marc Zyngier
2020-01-22 18:56 ` Marc Zyngier
2020-01-22 18:56 ` Marc Zyngier
2020-01-24 12:20 ` Quentin Perret
2020-01-24 12:20 ` Quentin Perret
2020-01-24 12:20 ` Quentin Perret
2020-01-24 13:34 ` Marc Zyngier
2020-01-24 13:34 ` Marc Zyngier
2020-01-24 13:34 ` Marc Zyngier
2020-01-24 14:02 ` Quentin Perret [this message]
2020-01-24 14:02 ` Quentin Perret
2020-01-24 14:02 ` Quentin Perret
2020-01-23 11:59 ` Mike Rapoport
2020-01-23 11:59 ` Mike Rapoport
2020-01-23 11:59 ` Mike Rapoport
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=20200124140237.GA180536@google.com \
--to=qperret@google.com \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=maz@kernel.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.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.