Hi, On Tue, Sep 04, 2012 at 03:05:51PM +0200, Marek Szyprowski wrote: > Hi Felibe, > > On Friday, August 31, 2012 2:21 PM Felipe Balbi wrote: > > > On Fri, Aug 31, 2012 at 01:39:21PM +0200, Andrzej Pietrasiewicz wrote: > > > On Friday, August 31, 2012 12:12 PM Felipe Balbi wrote: > > > > > > <snip> > > > > > > > Unless it can be proven that ccg has active users, we should get rid of it > > > > for now before someone starts using it and we need to maintain the ABI for > > > > the next 10 years. > > > > > > We need a configurable composite gadget in the Tizen platform to > > > provide sdbd connectivity and mass storage function at the same time. > > > > You don't need a "configurable composite gadget" if you always have > > storage and sdbd (btw, what's sdbd ? is that provided by ccg ? I don't > > think so). A static (temporarily out-of-tree) tizen gadget would > > suffice, once we move to configfs Tizen can start using that. > > > > IMHO, that'll be a much lower impact on Tizen's platform. I'm also > > concerned that after you start using it and we try to change, it'll just > > be an argument to keep CCG as is, since it is an interface to userland > > after all, and I don't want to maintain ccg for the next 10 years as > > it's clearly wrong approach. > > CCG (as well as Android gadget) provides functionality that was not provided > by any of the gadgets before. As You have noticed once, all existing gadget > had static configuration and the only possibility to change configuration > (implied as a set of available usb functions) is to create, compile and load > yet another gadget module. Such feature is really needed for our Linux > platform to replace developped-off-the-kernel old android gadget. > > We were pleased when we saw that there was a will to develop an android-like > gadget for mainline kernel and the patches posted to ml late in December 2011. > Then, because of lack of progress we decided to continue those works on our > own. We managed to resolve most of the issues in the Android gadget and > extended it with functionfs support, which was crucial for implementing all > functions that are needed for our platform (a replacement for adb-shell called > sbsd and mtp protocol are implemented by respective daemons in userland). Our > CCG got finally merged to staging. > > The only missing piece was conversion to configfs. When we were posting ccg to > staging tree, we thought that this can be done incrementally. In meantime we > had something what was fully functional and demonstrated that it can fully > replace old Android gadget with some simple changes to userspace tools. > > The conversion to configfs tuned out to be a complete rewrite from scratch of > the whole usb gadget subsystem, what is a huge task. Andrzej continues his > works in this area, but I don't expect it to be ready for v3.7 or even v3.8. > In meanwhile CCG serves as a working solution for us. It lives in staging, > so noone should expect that it's interface is stable, so I don't see any > problem in replacing it with configfs driver solution in the future. The problem is that ccg is completely wrong implementation WRT moving to configfs. ccg decided that it was so special that it could overwrite composite.c's setup function. The whole idea behind configfs was to drop the need for mass_storage.c, nokia.c, cdc2.c, etc, but ccg decided that it would create yet another $whatever.c file for combining the functions into a gadget. On top of all that, ccg is making it really difficult for Sebastian to continue his big, highly needed, cleanup of the gadget framework and ccg isn't even "part of the main kernel" (notice the quotation marks) since it lies in staging tree. If you think you really need ccg, then we are very happy to take patches from you fixing it and cleaning it up, but we cannot delay the whole configfs part because ccg decided to be special. I would still recommend dropping ccg so we can move faster with configfs migration, though, as that would be something which should work for Tizen, Android and anybody else. -- balbi
Attachment:
signature.asc
Description: Digital signature
