Re: [Devel] [PATCH] ACPICA: Fix compilation with bare-metal toolchian
by Rafael J. Wysocki
On Saturday, June 22, 2019 11:03:54 PM CEST Laster K. wrote:
> An ifdef expects to be compiled with full-fledged Linux toolchain,
> but it's common to compile kernel with just bare-metal toolchain
> which doesn't define __linux__. So, also add __KERNEL__ check.
>
> Signed-off-by: Laster K. (lazerl0rd) <officiallazerl0rd(a)gmail.com>
> ---
> Apologies for the multiple/spammed e-mails, I was having mail client issues.
>
> include/acpi/platform/acenv.h | 2 +-
> include/acpi/platform/acenvex.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
> index 35ab3f87cc29..b69319198cb8 100644
> --- a/include/acpi/platform/acenv.h
> +++ b/include/acpi/platform/acenv.h
> @@ -148,7 +148,7 @@
>
> #endif
>
> -#if defined(_LINUX) || defined(__linux__)
> +#if defined(_LINUX) || defined(__KERNEL__) || defined(__linux__)
> #include <acpi/platform/aclinux.h>
>
> #elif defined(_APPLE) || defined(__APPLE__)
> diff --git a/include/acpi/platform/acenvex.h b/include/acpi/platform/acenvex.h
> index 2e36c8344897..c7697a47e33f 100644
> --- a/include/acpi/platform/acenvex.h
> +++ b/include/acpi/platform/acenvex.h
> @@ -19,7 +19,7 @@
> *
> *****************************************************************************/
>
> -#if defined(_LINUX) || defined(__linux__)
> +#if defined(_LINUX) || defined(__KERNEL__) || defined(__linux__)
> #include <acpi/platform/aclinuxex.h>
>
> #elif defined(__DragonFly__)
>
Erik, Bob, any input here?
2 years, 6 months
Re: [Devel] [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings
by Moore, Robert
We've taken the change to ACPI_TO_POINTER.
Thanks,
Bob
-----Original Message-----
From: Qian Cai [mailto:cai@lca.pw]
Sent: Thursday, July 18, 2019 12:49 PM
To: Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>
Cc: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik <erik.schmauss(a)intel.com>; jkim(a)FreeBSD.org; lenb(a)kernel.org; ndesaulniers(a)google.com; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; clang-built-linux(a)googlegroups.com; linux-kernel(a)vger.kernel.org; Qian Cai <cai(a)lca.pw>
Subject: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings
Clang generate quite a few of those warnings.
drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Wnull-pointer-arithmetic]
status = acpi_get_handle(ACPI_ROOT_OBJECT,
obj->string.pointer,
^~~~~~~~~~~~~~~~
./include/acpi/actypes.h:458:56: note: expanded from macro 'ACPI_ROOT_OBJECT'
#define ACPI_ROOT_OBJECT ((acpi_handle) ACPI_TO_POINTER
(ACPI_MAX_PTR))
^~~~~~~~~~~~~~~
./include/acpi/actypes.h:509:41: note: expanded from macro 'ACPI_TO_POINTER'
#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0,
(acpi_size) (i))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/acpi/actypes.h:503:84: note: expanded from macro 'ACPI_ADD_PTR'
#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t,
(ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
^~~~~~~~~~~~~~~~~
./include/acpi/actypes.h:501:66: note: expanded from macro 'ACPI_CAST_PTR'
#define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
^ This is because pointer arithmetic on a pointer not pointing to an array is an undefined behavior (C11 6.5.6, constraint 8). Fix it by just casting the corresponding pointers using ACPI_CAST_PTR() and skip the arithmetic. Also, fix a checkpatch warning together.
ERROR: Macros with complex values should be enclosed in parentheses
#45: FILE: include/acpi/actypes.h:509:
+#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i)
Signed-off-by: Qian Cai <cai(a)lca.pw>
---
v2: Use ACPI_CAST_PTR() in ACPI_TO_POINTER() directly without
arithmetic.
include/acpi/actypes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index ad6892a24015..163181e2d884 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -506,7 +506,7 @@ typedef u64 acpi_integer;
/* Pointer/Integer type conversions */
-#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, (acpi_size) (i))
+#define ACPI_TO_POINTER(i) (ACPI_CAST_PTR (void, i))
#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
#define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
--
2.20.1 (Apple Git-117)
2 years, 11 months
[pm:pm-s2idle-testing 9/12] drivers/acpi/ec.c:1061:6: error: implicit declaration of function 'pm_suspend_no_platform'; did you mean 'suspend_nvs_restore'?
by kbuild test robot
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-s2idle-testing
head: 4bf4770939f0f44bcabdd02e15cc18bd683a2734
commit: 2f0dd704ceda376492d18398b659513077de672c [9/12] ACPI: PM: Set up EC GPE for system wakeup from drivers that need it
config: x86_64-randconfig-g004-201929 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
git checkout 2f0dd704ceda376492d18398b659513077de672c
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp(a)intel.com>
All errors (new ones prefixed by >>):
drivers/acpi/ec.c:1052:6: error: redefinition of 'acpi_ec_mark_gpe_for_wake'
void acpi_ec_mark_gpe_for_wake(void)
^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/acpi/ec.c:29:0:
include/linux/acpi.h:944:20: note: previous definition of 'acpi_ec_mark_gpe_for_wake' was here
static inline void acpi_ec_mark_gpe_for_wake(void) {}
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/acpi/ec.c:1059:6: error: redefinition of 'acpi_ec_set_gpe_wake_mask'
void acpi_ec_set_gpe_wake_mask(u8 action)
^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/acpi/ec.c:29:0:
include/linux/acpi.h:945:20: note: previous definition of 'acpi_ec_set_gpe_wake_mask' was here
static inline void acpi_ec_set_gpe_wake_mask(u8 action) {}
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/acpi/ec.c: In function 'acpi_ec_set_gpe_wake_mask':
>> drivers/acpi/ec.c:1061:6: error: implicit declaration of function 'pm_suspend_no_platform'; did you mean 'suspend_nvs_restore'? [-Werror=implicit-function-declaration]
if (pm_suspend_no_platform() && first_ec && !ec_no_wakeup)
^~~~~~~~~~~~~~~~~~~~~~
suspend_nvs_restore
cc1: some warnings being treated as errors
vim +1061 drivers/acpi/ec.c
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2 years, 11 months
[pm:pm-s2idle-testing 9/12] drivers/acpi/ec.c:1061:2: error: implicit declaration of function 'pm_suspend_no_platform'
by kbuild test robot
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-s2idle-testing
head: 4bf4770939f0f44bcabdd02e15cc18bd683a2734
commit: 2f0dd704ceda376492d18398b659513077de672c [9/12] ACPI: PM: Set up EC GPE for system wakeup from drivers that need it
config: x86_64-randconfig-s0-07260935 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 2f0dd704ceda376492d18398b659513077de672c
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp(a)intel.com>
All errors (new ones prefixed by >>):
drivers/acpi/ec.c: In function 'acpi_ec_set_gpe_wake_mask':
>> drivers/acpi/ec.c:1061:2: error: implicit declaration of function 'pm_suspend_no_platform' [-Werror=implicit-function-declaration]
if (pm_suspend_no_platform() && first_ec && !ec_no_wakeup)
^
cc1: some warnings being treated as errors
vim +/pm_suspend_no_platform +1061 drivers/acpi/ec.c
1058
1059 void acpi_ec_set_gpe_wake_mask(u8 action)
1060 {
> 1061 if (pm_suspend_no_platform() && first_ec && !ec_no_wakeup)
1062 acpi_set_gpe_wake_mask(NULL, first_ec->gpe, action);
1063 }
1064 EXPORT_SYMBOL_GPL(acpi_ec_set_gpe_wake_mask);
1065
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2 years, 11 months
Re: [Devel] [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
by Moore, Robert
-----Original Message-----
From: Qian Cai [mailto:cai@lca.pw]
Sent: Wednesday, July 24, 2019 6:40 AM
To: Moore, Robert <robert.moore(a)intel.com>; Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; Schmauss, Erik <erik.schmauss(a)intel.com>; jkim(a)freebsd.org; Len Brown <lenb(a)kernel.org>; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; clang-built-linux <clang-built-linux(a)googlegroups.com>; LKML <linux-kernel(a)vger.kernel.org>
Subject: Re: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
On Tue, 2019-07-23 at 20:49 +0000, Moore, Robert wrote:
> > > Signed-off-by: Qian Cai <cai(a)lca.pw>
> > > ---
> > > include/acpi/actypes.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > > ad6892a24015..25b4a32da177 100644
> > > --- a/include/acpi/actypes.h
> > > +++ b/include/acpi/actypes.h
> > > @@ -500,13 +500,13 @@ typedef u64 acpi_integer;
> > >
> > > #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t)
> > > (p)) #define ACPI_CAST_INDIRECT_PTR(t, p) ((t **)
> > > (acpi_uintptr_t) (p)) -#define ACPI_ADD_PTR(t, a, b)
> > > ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
> > > +#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (a) +
> > > (acpi_size)(b))
>
> We have some questions concerning this change. If (a) is not cast to a
> u8, the addition will be in whatever units are appropriate for (a)
> i.e., the type of (a). However, we want ACPI_ADD_PTR (And
> ACPI_SUB_PTR) to simply perform a byte addition or subtraction - thus
> the cast to u8. I believe that is the original thinking behind the macros.
I posted a v2 a while ago, and should clear this concern.
OK then this change only affects ACPI_TO_POINTER?
+#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i)
>
> > > #define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t,
> > > (ACPI_CAST_PTR (u8, (a)) - (acpi_size)(b))) #define
> > > ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8,
> > > (a)) - ACPI_CAST_PTR (u8, (b))))
> > >
> > > /* Pointer/Integer type conversions */
> > >
> > > -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void
> > > *) 0,
> > > (acpi_size) (i))
> > > +#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, 0,
> > > (acpi_size) (i))
> >
> > IIUC, these are adding `i` to NULL (or (void*)0)? X + 0 == X ?
> > --
> > Thanks,
> > ~Nick Desaulniers
>
>
2 years, 11 months
Re: [Devel] [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
by Moore, Robert
-----Original Message-----
From: Qian Cai [mailto:cai@lca.pw]
Sent: Wednesday, July 17, 2019 5:50 PM
To: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik <erik.schmauss(a)intel.com>; jkim(a)freebsd.org; Len Brown <lenb(a)kernel.org>; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; clang-built-linux <clang-built-linux(a)googlegroups.com>; LKML <linux-kernel(a)vger.kernel.org>
Subject: Re: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
> On Jul 17, 2019, at 6:01 PM, Nick Desaulniers <ndesaulniers(a)google.com> wrote:
>
> On Tue, Jul 16, 2019 at 8:38 PM Qian Cai <cai(a)lca.pw> wrote:
>>
>> Clang generate quite a few of those warnings.
>>
>> drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer
>> treated as a cast from integer to pointer is a GNU extension
>> [-Wnull-pointer-arithmetic]
>> status = acpi_get_handle(ACPI_ROOT_OBJECT,
>> obj->string.pointer,
>> ^~~~~~~~~~~~~~~~
>> ./include/acpi/actypes.h:458:56: note: expanded from macro
>> 'ACPI_ROOT_OBJECT'
>> #define ACPI_ROOT_OBJECT ((acpi_handle) ACPI_TO_POINTER
>> (ACPI_MAX_PTR))
>>
>> ^~~~~~~~~~~~~~~
>> ./include/acpi/actypes.h:509:41: note: expanded from macro
>> 'ACPI_TO_POINTER'
>> #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0,
>> (acpi_size) (i))
>>
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/acpi/actypes.h:503:84: note: expanded from macro
>> 'ACPI_ADD_PTR'
>> #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t,
>> (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
>> ^~~~~~~~~~~~~~~~~
>> ./include/acpi/actypes.h:501:66: note: expanded from macro
>> 'ACPI_CAST_PTR'
>> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
>> ^
>> This is because pointer arithmetic on a pointer not pointing to an
>> array is an undefined behavior. Fix it by doing an integer arithmetic
>> instead.
>
> Hi Qian, thanks for the patch. How do I reproduce this issue,
> precisely? I just tried:
> $ make CC=clang -j71 drivers/acpi/scan.o on linux-next today and don't
> observe the warning. My clang is ToT built sometime this week. It
> looks like drivers/acpi/scan.o when CONFIG_ACPI=y, which is set in the
> defconfig. Is there another set of configs to enable to observe the
> warning?
# make W=1 -j 256
With the config,
https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
>
> Also, the fix is curious. Arithmetic on pointers to different
> "objects" (with one element passed the end) may lead to provence
> issues due to undefined behavior, but I would have expected some cases
> to uintptr_t, then arithmetic on that type, as the solution (which is
> what I suspect ACPI_CAST_PTR is doing).
>
> Further, you seem to have modified ACPI_ADD_PTR but not ACPI_SUB_PTR;
> I would have expected both to be afflicted together or not at all
> based on their existing implementations.
Yes, I thought about that, but ACPI_SUB_PTR does not seem used anywhere, so I thought maybe just start a new discussion to remove it all together later.
ACPI_SUB_PTR is used in the iasl data table compiler.
>
>>
>> Signed-off-by: Qian Cai <cai(a)lca.pw>
>> ---
>> include/acpi/actypes.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
>> ad6892a24015..25b4a32da177 100644
>> --- a/include/acpi/actypes.h
>> +++ b/include/acpi/actypes.h
>> @@ -500,13 +500,13 @@ typedef u64 acpi_integer;
>>
>> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
>> #define ACPI_CAST_INDIRECT_PTR(t, p) ((t **) (acpi_uintptr_t) (p))
>> -#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
>> +#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (a) + (acpi_size)(b))
We have some questions concerning this change. If (a) is not cast to a u8, the addition will be in whatever units are appropriate for (a) i.e., the type of (a). However, we want ACPI_ADD_PTR (And ACPI_SUB_PTR) to simply perform a byte addition or subtraction - thus the cast to u8. I believe that is the original thinking behind the macros.
>> #define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) - (acpi_size)(b)))
>> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b))))
>>
>> /* Pointer/Integer type conversions */
>>
>> -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, (acpi_size) (i))
>> +#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, 0, (acpi_size) (i))
>
> IIUC, these are adding `i` to NULL (or (void*)0)? X + 0 == X ?
> --
> Thanks,
> ~Nick Desaulniers
2 years, 11 months
Re: [Devel] PROBLEM: Calling ObjectType on buffer field reports type integer
by Schmauss, Erik
> -----Original Message-----
> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> Sent: Saturday, July 20, 2019 1:45 PM
> To: Schmauss, Erik <erik.schmauss(a)intel.com>; Moore, Robert
> <robert.moore(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: Re: PROBLEM: Calling ObjectType on buffer field reports type integer
>
> On 3/22/19 10:28 PM, Schmauss, Erik wrote:
> > I've been discussing this with Bob. I've decided to file a bug against
> > Microsoft internally. I would like to wait and see what they say...
> > I've never done such things so I don't know how long the process takes to get
> a response form them.
> >
> > I'll post updates when I get them but feel free to ping us again in a
> > few weeks if you don't hear back. We're still investigating their
> > operation region behavior as well...
> >
> > Erik
>
> Hi,
>
> I assume there hasn't been any response from Microsoft?
Sorry about the late response. This slipped through the cracks.
I've sent them an email just now and I'll keep you informed
Thanks,
Erik
>
> Maximilian
2 years, 11 months
Re: [Devel] [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests
by Rafael J. Wysocki
On Tue, Jul 16, 2019 at 12:14 PM Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
>
> On 16-07-19, 12:06, Rafael J. Wysocki wrote:
> > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> > >
> > > Hello,
> > >
> > > Now that cpufreq core supports taking QoS requests for min/max cpu
> > > frequencies, lets migrate rest of the users to using them instead of the
> > > policy notifiers.
> >
> > Technically, this still is linux-next only. :-)
>
> True :)
>
> > > The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are
> > > removed as a result, but we have to add CPUFREQ_CREATE_POLICY and
> > > CPUFREQ_REMOVE_POLICY events to it for the acpi stuff specifically. So
> > > the policy notifiers aren't completely removed.
> >
> > That's not entirely accurate, because arch_topology is going to use
> > CPUFREQ_CREATE_POLICY now too.
>
> Yeah, I thought about that while writing this patchset and
> coverletter. But had it not been required for ACPI, I would have done
> it differently for the arch-topology code. Maybe direct calling of
> arch-topology routine from cpufreq core. I wanted to get rid of the
> policy notifiers completely but I couldn't find a better way of doing
> it for ACPI stuff.
>
> > > Boot tested on my x86 PC and ARM hikey board. Nothing looked broken :)
> > >
> > > This has already gone through build bot for a few days now.
> >
> > So I'd prefer patches [5-8] to go right after the first one and then
> > do the cleanups on top of that, as somebody may want to backport the
> > essential changes without the cleanups.
>
> In the exceptional case where nobody finds anything wrong with the
> patches (highly unlikely), do you want me to resend with reordering or
> you can reorder them while applying? There are no dependencies between
> those patches anyway.
Please resend the reordered set when the merge window closes.
2 years, 11 months
Re: [Devel] [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests
by Rafael J. Wysocki
On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
>
> Hello,
>
> Now that cpufreq core supports taking QoS requests for min/max cpu
> frequencies, lets migrate rest of the users to using them instead of the
> policy notifiers.
Technically, this still is linux-next only. :-)
> The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are
> removed as a result, but we have to add CPUFREQ_CREATE_POLICY and
> CPUFREQ_REMOVE_POLICY events to it for the acpi stuff specifically. So
> the policy notifiers aren't completely removed.
That's not entirely accurate, because arch_topology is going to use
CPUFREQ_CREATE_POLICY now too.
> Boot tested on my x86 PC and ARM hikey board. Nothing looked broken :)
>
> This has already gone through build bot for a few days now.
So I'd prefer patches [5-8] to go right after the first one and then
do the cleanups on top of that, as somebody may want to backport the
essential changes without the cleanups.
2 years, 11 months