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: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net>
Date:   Thu, 16 Nov 2017 20:30:24 +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.

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

> The risk is bigger than the merit by applying the patch.

I suggest to reconsider this view.

Would you dare to follow any of the presented arguments?

> So, just prove that your patch doesn't break anything.

Which kind of information would you find sufficient for a “prove”?

> Doesn't matter whether it's a test with real hardware
> or with systematic checks.

I assume that your development concerns matter more in this case.

> Once when it's confirmed, we can apply it.

I am curious if other contributors will become interested to confirm something.

> A very simple rule,

It might occasionally look simpler than it is in “special cases”.

> and this will be valid for most of other subsystems, too.

The response is also varying there as usual.

A few update suggestions from the discussed pattern were integrated
(also by you) already.
Would you like to continue with similar support in any ways?

Regards,
Markus