linux-kernel - Re: [PATCH v4 0/3] USB Audio Gadget refactoring

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] [day] [month] [year] [list]

Date:   Tue, 6 Jun 2017 22:43:22 +0300
From:   Ruslan Bilovol <ruslan.bilovol@...il.com>
To:     Felipe Balbi <balbi@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Daniel Mack <zonque@...il.com>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Clemens Ladisch <clemens@...isch.de>,
        Jonathan Corbet <corbet@....net>,
        Peter Chen <hzpeterchen@...il.com>,
        Julian Scheel <julian@...st.de>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        linux-doc@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/3] USB Audio Gadget refactoring

On Tue, Jun 6, 2017 at 12:41 PM, Felipe Balbi <balbi@...nel.org> wrote:
>
> Hi,
>
> Greg KH <gregkh@...uxfoundation.org> writes:
>>> > I'm OK with dropping legacy f_uac1 implementation.
>>> >
>>> > Another idea I was thinking about is to implement simple in-kernel
>>> > driver which will do the same as existing alsaloop tool userspace
>>> > tool does (so legacy users will need to load two kernel modules
>>> > and get same functionality). But this seems to be a wrong way,
>>> > since It known that Linux kernel community doesn't like to take drivers
>>> > with same functionality as existing userspace tools already have.
>>> >
>>> > So bottom line: since I'm not a legacy f_uac1 user, there is no
>>> > difference for me how to handle it - remove legacy f_uac1 completely,
>>> > rename it to f_uac1_legacy or add separate f_uac1_acard function.
>>> >
>>> > So if dropping of legacy f_uac1 implementation is OK for you,
>>> > I can do it quickly in next patchset.
>>>
>>> Personally, I don't want duplicated functionality and I think the
>>> virtual sound card approach is much better. Then again, removing
>>> functionality we already support is kind of odd.
>>>
>>> Greg, Alan, what do you guys think? Do we keep a duplicated function
>>> around or do we just tell people to rely on alsaloop? Personally, I
>>> think we're better off with the flexibility of the virtual sound card,
>>> what's your take?
>>
>> If the in-kernel driver will do more things, and we don't break the
>> existing setups using alsaloop, then I don't see the problem, except
>> that we now have to maintain two things :)
>>
>> If you don't mind the maintenance, fine with me...
>
> Okay, I don't think many will continue to use f_uac1.c. Ruslan, can you
> update your series so that current f_uac1.c gets renamed to
> f_uac1_legacy.c and you introduce a *new* f_uac1.c instead?

Yes sure, I'll post an updated patch series soon

Best regards,
Ruslan