On Thu, Jan 24 2013, Felipe Balbi wrote: > the benefit is that we will be able to go ahed with configfs-based > binding and will be able to drop duplicated gadget code between legacy > (non-composite) and composite framework with the function drivers. I'm not sure whether keeping gadgetfs around is such a big issue though. It would be legacy, deprecated piece of code which cannot be used with composite functions, but so what? Obviously I won't be stopping anyone from creating a compatibility layer, but I really don't think it's worth it. If it were, I'd write functionfs to use gadgetfs' interface in the first place. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo--
Attachment:
pgpf0MJUwefTt.pgp
Description: PGP signature
