linux-kernel - Re: ALSA: nm256: Fine-tuning for three function implementations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Nov 2017 10:50:21 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Takashi Iwai <tiwai@...e.de>, alsa-devel@...a-project.org
Cc:     Arvind Yadav <arvind.yadav.cs@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>,
        kernel-janitors@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: ALSA: nm256: Fine-tuning for three function implementations

>> There can be additional means be used to reduce the probability
>> of undesired side effects.
> 
> Irrelevant,

I got an other opinion here.

> it doesn't fix a bug,

Did I suggest to correct a coding style “bug”?

> nor dramatic improvement.

I agree that the change could be small only for this software module alone.
I guess that we discuss not only change patterns for this one
but also other affected modules here (besides a concrete example).
The result summary might be more significant overall.

>>> It must be "almost perfect" for such a code refactoring.
>>
>> Can you get the impression that the shown transformation patterns were correctly
>> applied for the source file “sound/pci/nm256/nm256.c”?
> 
> Impression doesn't matter.

It seems then that you can not get the kind of information you might be looking for
at the moment from me (alone).

> The question is whether it's 100% correct or not in such a case.

Would any other source code reviewers like to provide a corresponding acknowledgement
for concrete changes?

>> Are there any more software developers and code reviewers available
>> who would like to point another programming mistake out for this Linux module?
> 
> If you have find such, then it's fine, you can get your patches
> reviewed and more assured.

I hope that mailing list readers could offer something.

> But in the current situation, no one else is interested in it,
> and that's going to nowhere.

Did this software module become “too old”?

> The *really* trivial ones were applied.  The rest are not.

Can higher level transformation patterns become easier to accept
by any other means?

>> Do you need any more information to see and eventually accept the sense again?
> 
> No.  This kind of code refactoring has no more information.
> It's a "trivial" change, after all.

Would you like to distinguish the possible update steps better to avoid
further confusion around “triviality”?

>> Are you using a continuous integration system?
> 
> Not really in my side.  But there are others doing that.

How much does the omission of such an useful development tool
influence your concerns?

Would you like to improve the software situation in any ways there?

Regards,
Markus