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

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]


Hi,

Greg KH <gregkh@linuxfoundation.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?

Thanks a lot

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]