linux-kernel - Re: Lindent formatting issues

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:	Thu, 19 Dec 2013 17:30:02 +0000
From:	Laszlo Papp <lpapp@....org>
To:	Joe Perches <joe@...ches.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Lindent formatting issues

On Thu, Dec 19, 2013 at 4:32 PM, Joe Perches <joe@...ches.com> wrote:
> On Thu, 2013-12-19 at 16:17 +0000, Laszlo Papp wrote:
>> On Tue, Dec 17, 2013 at 8:05 PM, Joe Perches <joe@...ches.com> wrote:
> []
>> > You could also use scripts/checkpatch.pl with
>> > the --fix option.
>> >
>> > ./scripts/checkpatch.pl -f --fix <file>
>> >
>> > with various --types=<TYPE,...> options.
>> >
>> > Maybe use: https://lkml.org/lkml/2013/9/23/504
>>
>> Thanks Joe. I seem to have further issues with this tool... I tried to
>> run it on a file I patched, but it generated a lot of noise unrelated
>> to my logical change... :(
>
> checkpatch is really for patches.  Using -f is a
> convenience ability.  You can limit what messages
> checkpatch emits by using "--types=<FOO[,BAR...]>"
>
> You can show what message classifications are being
> used by adding "--show-types".
>
>> Do you happen to know what the best way is to fix it in such cases? I
>> am providing some examples below:
>>
>>         if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_fan1_fault.dev_attr
>> -        || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>> +           || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
>> +           || devattr == &sensor_dev_attr_fan1_fault.dev_attr
>> +           || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
>> +           || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>
> Well, here the general kernel style is to put
> the logical && or || test at the end of the
> previous line so:
>
>         if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_fan1_fault.dev_attr ||
>             devattr == &sensor_dev_attr_gpio1_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>
> would likely be preferred.
>
>> -                                   int n)
>> +                                    int n)
>
> This may be indentation alignment but I don't follow
> how this is a problem.

It is a problem because it is a noise for a logical change that is not
about whitespace fixup. The kernel maintainer would probably
rightfully reject it with such a line in.

>
>> -       int sysfs_modes[4] = {0, 1, 2, 1};
>> +       int sysfs_modes[4] = { 0, 1, 2, 1 };
>
> Is this change from Lindent or checkpatch?

I have used Lindent when these lines were generated. Here is some more:

-               data->dac = 180 - (180 * pwm)/255;
+               data->dac = 180 - (180 * pwm) / 255;
        else
-               data->dac = 76 - (76 * pwm)/255;
+               data->dac = 76 - (76 * pwm) / 255;

...

-       .probe          = max6650_probe,
-       .remove         = max6650_remove,
-       .id_table       = max6650_id,
+       .probe          = max6650_probe,
+       .remove = max6650_remove,
+       .id_table = max6650_id,

...

-                        const char *buf, size_t count)
+                         const char *buf, size_t count)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/