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: <s5hy3mqr5v9.wl-tiwai@suse.de>
Date:   Tue, 28 Nov 2017 12:37:46 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     alsa-devel@...a-project.org,
        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

On Tue, 28 Nov 2017 10:50:21 +0100,
SF Markus Elfring wrote:
> 
> >> There can be additional means be used to reduce the probability
> >> of undesired side effects.
> > 
> > Irrelevant,
> 
> I got an other opinion here.

Not from me.

> > it doesn't fix a bug,
> 
> Did I suggest to correct a coding style “bug”?

No.  A coding style issue is never a 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.

No.

> >>> 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).

No, the patch itself speaks.

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

If you get more reviewed-by from others, it means already it's safer
to apply.  Then I can take it.  But without that, it's obviously no
material to take.

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

Let's hope.

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

Mostly the hardware is too old, or the change itself isn't interesting
enough.

> > The *really* trivial ones were applied.  The rest are not.
> 
> Can higher level transformation patterns become easier to accept
> by any other means?

Only if it's assured to work and not to break anything else.

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

Learn from the past.

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

Can't judge unless I really see / use it.

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

I *hope*, but only when it's not too annoying.


Takashi