On Wed, Aug 15, 2012 at 07:54:35AM -0700, Greg Kroah-Hartmann wrote: > On Wed, Aug 15, 2012 at 05:37:50PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Wed, Aug 15, 2012 at 06:30:20AM -0700, Greg Kroah-Hartmann wrote: > > > On Wed, Aug 15, 2012 at 10:36:14AM +0200, Sebastian Andrzej Siewior wrote: > > > > On the TODO list I read convert from sysfs to configfs. Great. That > > > > means it should become what I suggested some time ago. > > > > > > > > The ccg code is thight on sysfs, there is hardly generic code available > > > > which could be reused with the configfs interface. > > > > So can we remove ccg from staging right away? I don't see the point in > > > > keeping it. The user interface changes completely. And while I convert > > > > in tree gadgets / composite users I have to update ccg for no reason. > > > > Ach, I am probably okay with helping Andrzej with his configfs work. > > > > > > > > Okay to remove it? > > > > > > Why would you remove it if people are still using it today? Don't you > > > want to fix it up properly and move it into the real part of the kernel > > > instead? > > > > that's actually why I was against accepting the Android gadget in the > > kernel in any way or format. The thing is completely wrong. They created > > a gadget where you can remove and add functions through sysfs. > > Yes, I don't really like it, but due to the fact that they are shipping > a few million devices using this a day, I kind of want to at least give > people a chance to have the code, just like I did for the rest of the > Android code that is in the staging directory. > > > What me and Sebastian as trying to achieve with the gadget configfs > > interface, is get rid of all gadget drivers (nokia.c, zero.c, > > file_storage.c, etc) and keep only function drivers (f_*.c) in the > > kernel. Then the entire gadget/configuration/interface binding will be > > done through userland allowing any type of functions mix ups you can > > think of without having to add yet another > > my_new_gadget_with_a_slightly_different_function.c driver to the kernel > > tree. > > And that's a wonderful and worthy goal, keep up the great work :) > > > Android gadget was simply renamed to ccg and they sneaked into the > > kernel through the staging tree. That's a little unfair provided I was > > against the driver for several reasons. But that's fine, we can learn to > > live with that. > > It didn't "sneak" in. I kept asking and asking for it, I thought I was > rather loud about it...
Fair enough. We will see what we can do. In the worst case scenario, we can keep inode.c and ccg out of the rework (continue to support the legacy mode for those two cases for a while) and, maybe, help android folks update their code to use configfs. Hopefully in 3 years we can drop ccg and inode.c :-p Cheers -- balbi
signature.asc
Description: Digital signature
