lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 5 May 2023 06:15:19 -0700
From:   James Seo <james@...iv.tech>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     James Seo <james@...iv.tech>, Jean Delvare <jdelvare@...e.com>,
        Jonathan Corbet <corbet@....net>, linux-hwmon@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 02/11] hwmon: (core) Rename last parameter of
 devm_hwmon_register_with_info()

On Thu, May 04, 2023 at 08:29:57AM -0700, Guenter Roeck wrote:
> Please please please no such changes. I don't want to have to deal with
> patch wars just because people believe variables should have other names.
> 
> Such changes add zero value unless one counts wasted review time as a "value".
> 
> Guenter
>

Hello,

Of course arbitrarily changing variable names is pointless. But this
patch fulfills the intent of 848ba0a2f20dc121a3ef5272a24641d2bd963d8b,
which makes this change for devm_hwmon_device_register_with_info() in
hwmon-kernel-api.txt and in hwmon.h - but not in hwmon.c. The same
commit makes the same change for hwmon_device_register_with_info() in
all three files, so it obviously should have been in tree already.

The other reason for this patch is that for the purpose of generating
function documentation from kerneldocs, it is not feasible to call
this parameter "extra_groups" in the kerneldoc and still call it
"groups" in the function itself. Doing so results in the lines
"const struct attribute_group **groups / undescribed" and no mention
of "extra_groups" in the generated document. Leaving things as is, so
that [devm_]hwmon_device_register_with_info() have different names
for this parameter, is potentially confusing and more noticeable to
to the eye than I would like once rendered.

Is this good enough to proceed? And as a subsystem maintainer, is
there anything else, specifically or in general, that you would like
to see addressed?

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ