linux-kernel - Re: [PATCH 2/3] ALSA: Implement the new virtual driver

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: <6f6d09b3-39e7-58b6-221f-6276d3ce213a@gmail.com>
Date:   Sun, 14 May 2023 14:08:53 +0400
From:   Ivan Orlov <ivan.orlov0322@...il.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     corbet@....net, akpm@...ux-foundation.org, perex@...ex.cz,
        tiwai@...e.com, broonie@...nel.org, skhan@...uxfoundation.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        alsa-devel@...a-project.org, linux-kselftest@...r.kernel.org,
        gregkh@...uxfoundation.org, himadrispandya@...il.com,
        linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH 2/3] ALSA: Implement the new virtual driver

On 5/14/23 13:18, Takashi Iwai wrote:
> The idea is interesting, and it's a definitely good thing to have.
> 
> I wonder, though, whether it could be better provided as an extention
> to the existing snd-dummy driver.  The advantage of extending
> snd-dummy driver would be that it already supports different formats,
> etc.  OTOH, if we create an individual driver, the pro side is the
> simpleness of the code.
> 
> I'm inclined to go with a separate driver, but I'm open about this.
> Maybe Jaroslav and Mark have some opinions?
> 
> About this patch set: the driver name should be a bit more specific,
> as this isn't a generic virtual driver that is used for general
> purpose but it's only for testing.  And it's only for testing PCM.
> So, a name like snd-test-pcm would be more appropriate, IMO.
> 
> And, we want the coverage of different formats, channels, rates and
> accesses (interleaved vs non-interleaved).  How can we extend somehow
> more for that?
> 
> 
> thanks,
> 
> Takashi

Hello Takashi! Thank you for your reply. I fully agree with the naming 
issue, and I'll change it in the future versions of the patch set in 
case we choose to have it as a separate driver. I also prefer this 
option because in my opinion the use cases of these drivers are a little 
bit different. Also, I believe I can extend the driver to support 
different formats, channels and accesses in the near future.

Additionally, implementing these changes would be a perfect task for the 
end of the Linux Kernel Mentorship program I'm going through :) However, 
I'm open to other views on this, and I'm ready to move the functionality 
from my driver to the snd-dummy in case we prefer this option.

Thanks again for considering my changes!

Kind regards,
Ivan Orlov.