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... greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
