linux-kernel - Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if

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:	Sun, 3 Jan 2016 19:50:18 +0100
From:	SF Markus Elfring <elfring@...rs.sourceforge.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Julia Lawall <julia.lawall@...6.fr>, devel@...verdev.osuosl.org,
	kernel-janitors@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Lior Dotan <liodot@...il.com>,
	Christopher Harrer <charrer@...critech.com>
Subject: Re: [PATCH] staging-slicoss: Replace variable initialisations by
 assignments in slic_if_init()

>> I am a bit surprised that you do not like such source code fine-tuning.
> 
> It's moving stuff around for no real reason, why would I like it?

Can such fine-tuning result in positive effects for the run-time behaviour?


> Reading and reviewing and applying this type of stuff takes away from
> the time I have to spend reviewing and applying actual code fixes from
> other developers who are doing real and useful work.

I am aware that a lot of open issues are competing for your precious
software development attention.


> Remember maintainer's time is our most limited resource right now.

That is mostly usual.


> You are abusing that by wasting their time for no valid reason.

I find a couple of my update suggestions still valid. I agree that
the importance of proposed changes is varying.


>> Will related software improvements get another chance later (eventually together
>> with other changes)?
> 
> Define "improvements".  Did you fix an obvious bug?

Maybe. - It depends on the error classes you are interested in at the moment.


> Did you speed up the code in a measurable way?

My suggestions can result in measurable differences.


> Did you make the code easier to understand somehow?
> For this patch you did none of these things.

Thanks for your view on my approach.

Will it become acceptable to reduce the scope for any more variable
definitions in further function implementations?


> Code in staging needs to be moved out of staging, and this patch does
> nothing toward achieving that goal and it wastes people's time reviewing
> it to see if it is correct or not.

I am curious on the ways the discussed software can evolve further.

Regards,
Markus
--
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/