On Tue, Jun 6, 2017 at 12:41 PM, Felipe Balbi <balbi@xxxxxxxxxx> wrote: > > Hi, > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
