linux-kernel - Re: [PATCH 3/3] PCI: tegra: make const array err

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:   Wed, 7 Jul 2021 21:52:05 +0200
From:   Krzysztof Wilczyński <kw@...ux.com>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     thierry.reding@...il.com, lorenzo.pieralisi@....com,
        robh@...nel.org, bhelgaas@...gle.com, jonathanh@...dia.com,
        linux-tegra@...r.kernel.org, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 3/3] PCI: tegra: make const array err_msg static

Hi Christophe,

[...]
> > These should be trivial to fix.  The two pertaining to "quoted string
> > split across lines" would be something that we might or might not decide
> > to do anything about this - technically, as per the Linux kernel coding
> > style [1], we ought to fix this... but, this particular case is not
> > a terrible example, so I will leave this at your discretion.
> > 
> > What do you think?
> 
> Hi,
> I don't think it worth it.
> 
> Even for patch 2/3 about 'seq_printf' --> 'seq_puts' conversion, I'm not
> fully convinced myself that is useful.

I personally believe it's a good change.

For a literal string without any formatting using the seq_printf() is
much more involved for no reason, but aside of this small performance
improvement, it also has some value in demonstrating the correct usage
patterns - people spent more time reading kernel code and looking at how
to do things and use things to base their work on, so setting some
example is not a bad idea.

Albeit, it's a matter of point of view too, I suppose.

> Too trivial clean-ups only mess-up 'git blame' for no real added value.

Yes, there is a fine line with these.

> If you want these clean-ups, I can send a patch for it, but checkpatch
> output need sometimes to be ignored on files already in the tree. At least,
> this is my point of view.

No worries!  Thank you for giving it some thought!  I appreciate it. :)

	Krzysztof