[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKPOu+807-eZfGff7EHcWGn4PFCJACv2mGi54jtoHCy14_s5sA@mail.gmail.com>
Date: Mon, 9 Oct 2023 19:34:02 +0200
From: Max Kellermann <max.kellermann@...os.com>
To: Greg KH <greg@...ah.com>
Cc: Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] drivers/hwmon: add local variable for newly allocated attribute_group**
On Mon, Oct 9, 2023 at 7:27 PM Greg KH <greg@...ah.com> wrote:
>
> On Mon, Oct 09, 2023 at 06:57:35PM +0200, Max Kellermann wrote:
> > This allows the compiler to keep the pointer in a register and
>
> Maybe, maybe not, there's no guarantee for register usage.
Agree. But without this change, register usage is effectively
prevented (much of the time). With this change, there is a chance for
better code. Yeah, it's not a critical code path, and it's only a tiny
tiny optimization - but the real reason for this patch is ....
> > - hwdev->groups = kcalloc(ngroups, sizeof(*groups), GFP_KERNEL);
> > - if (!hwdev->groups) {
> > + hwdev->groups = new_groups = kcalloc(ngroups, sizeof(*new_groups), GFP_KERNEL);
>
> So you have a const pointer AND a non-const pointer pointing to the same
> thing?
.... so I can make "hwdev->groups" const, which wouldn't allow
modifying it. (This isn't obvious in this one patch, but a later patch
in the series does this.)
There are only few functions which allocate a new pointer-array
dynamically; all others are global variables which currently cannot be
"const". This patch set does some lifting to allow adding "const".
Powered by blists - more mailing lists