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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2cbef557-5f89-c630-e108-14ef2ce6b41a@users.sourceforge.net>
Date:   Tue, 28 Nov 2017 09:19:48 +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 is a general source code transformation pattern involved.
>>>> So I find that it is systematic.
>>>>
>>>> But I did not dare to develop a script variant for the semantic patch
>>>> language (Coccinelle software) which can handle all special use cases
>>>> as a few of them are already demonstrated in this tiny patch series.
>>>
>>> Then you're doing everything by hands,
>>
>> I am navigating through possible changes around the pattern
>> “Use common error handling code” mostly manually so far.
>>
>>
>>> and can be wrong
>>
>> Such a possibility remains as usual.
> 
> "As usual" doesn't suffice.

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

> 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”?

> The damage by a overseen mistake is much higher than the merit by such a patch.

Are there any more software developers and code reviewers available
who would like to point another programming mistake out for this Linux module?

> If the patch is about fixing a bug, it's a different story.

How do “deviations” from the coding style and the evolution of object code size
fit to this view here?

> Or it's about a really trivial change (e.g. your sizeof() conversion
> patches), I can check and apply easily.

My update selection can contain also trivial adjustments.

> But for other changes with more lines, it makes little sense.

Do you need any more information to see and eventually accept the sense again?

> Again, the risk of breakage increases while the merit is negligible.

We disagree about corresponding benefits at the moment.
Would any other contributors comment the situation a bit more?

>>> -- that's the heart of the problem.
>>
>> There might be related opportunities for further improvements.
>> Do you trust adjustments from an evolving tool more than
>> my concrete contributions?
> 
> Yes, loudly.

I noticed that the development status of tools which you might find nice
at the moment can be also questionable.

> I stop at this point, as the rest is simply a repeat from the previous mail.

Are you using a continuous integration system?

Regards,
Markus