linux-kernel - Re: [PATCH] cpuidle: sysfs: Use sysfs_emit/sysfs_emit

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] [day] [month] [year] [list]

Message-ID: <CABPSWR6uKR0fz1-jJcJ1_JCsBbXhHioUe3o02DMSP8T18y1T1Q@mail.gmail.com>
Date: Sat, 6 Sep 2025 22:52:11 +0530
From: vivek yadav <vivekyadav1207731111@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, daniel.lezcano@...aro.org, 
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH] cpuidle: sysfs: Use sysfs_emit/sysfs_emit_at instead of sprintf/scnprintf

>On Fri, Sep 5, 2025 at 8:22 PM Joe Perches <joe@...ches.com> wrote:
>>
>> On Fri, 2025-09-05 at 22:57 +0530, vivek yadav wrote:
>> > On Mon, Aug 25, 2025 at 8:58 PM <vivekyadav1207731111@...il.com> wrote:
>> > > >
>> > > > From: Vivek Yadav <vivekyadav1207731111@...il.com>
>> > > >
>> > > > The ->show() callbacks in sysfs should use sysfs_emit() or
>> > > > sysfs_emit_at()
>> []
>> > > > diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
>> []
>> > > > @@ -22,21 +22,21 @@ static ssize_t show_available_governors(struct device *dev,
>> > > >                                         struct device_attribute *attr,
>> > > >                                         char *buf)
>> > > >  {
>> > > > -       ssize_t i = 0;
>> > > > +       ssize_t len = 0;
>> > >
>> > > The variable rename is not necessary or even useful AFAICS ->
>> >
>> > There is no harm if we leave the variable name as 'i' but it would be better
>> > if we give it a suitable name like 'offset'. It will definitely improve
>> > readability.
>>
>> size and len are most commonly used.
>> I prefer len.
>
>Fine, in new code, use whatever you like, but what really is the
>reason for doing a rename in code that has been almost unchanged since
>2.6.22?

Hi Rafael,

You are correct that the variable name ‘i’ has remained unchanged
since v2.6.22. Its long-standing presence is understandable, but it
doesn’t necessarily mean it can’t be updated in the future if needed.

As @Joe pointed out, statistics show that most developers prefer using
more descriptive names such as ‘len’ or ‘size’ when possible.

With this in mind, I believe it’s time to bring this discussion to a
conclusion. Shall we move forward with this change in variable naming
— YES or NO?

Looking forward to your input.

Best regards,
Vivek

On Sat, Sep 6, 2025 at 12:43 PM Joe Perches <joe@...ches.com> wrote:
>
> On Fri, 2025-09-05 at 20:34 +0200, Rafael J. Wysocki wrote:
> > On Fri, Sep 5, 2025 at 8:22 PM Joe Perches <joe@...ches.com> wrote:
> > >
> > > On Fri, 2025-09-05 at 22:57 +0530, vivek yadav wrote:
> > > > On Mon, Aug 25, 2025 at 8:58 PM <vivekyadav1207731111@...il.com> wrote:
> > > > > >
> > > > > > From: Vivek Yadav <vivekyadav1207731111@...il.com>
> > > > > >
> > > > > > The ->show() callbacks in sysfs should use sysfs_emit() or
> > > > > > sysfs_emit_at()
> > > []
> > > > > > diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> > > []
> > > > > > @@ -22,21 +22,21 @@ static ssize_t show_available_governors(struct device *dev,
> > > > > >                                         struct device_attribute *attr,
> > > > > >                                         char *buf)
> > > > > >  {
> > > > > > -       ssize_t i = 0;
> > > > > > +       ssize_t len = 0;
> > > > >
> > > > > The variable rename is not necessary or even useful AFAICS ->
> > > >
> > > > There is no harm if we leave the variable name as 'i' but it would be better
> > > > if we give it a suitable name like 'offset'. It will definitely improve
> > > > readability.
> > >
> > > size and len are most commonly used.
> > > I prefer len.
> >
> > Fine, in new code, use whatever you like, but what really is the
> > reason for doing a rename in code that has been almost unchanged since
> > 2.6.22?
>
> If a sprintf -> sysfs_emit conversion is done, it's IMO better
> style to be consistent with the typical sysfs_emit uses.