> > > > I am just worried if we change the behaviour of using gadget > > > > driver, can it be accepted by user? If you think it can be > > > > accepted if we can have some docs, we can implement manually > > > > binding for gadget driver from now on. > > > > > > user shouldn't have to deal with direct module insertion/removal > > > (unless he's a developer and actually *wants* to do that). Docs are > > > already in tree. The entire configfs interface has been documented, > > > it's based on those documents that Matt started writing libusbg. > > > > > > -- > > > balbi > > > > Yes, gadget-configfs is a good direction. > > > > I would like to know your plan for other gadget drivers > > (g_mass_storage, g_webcam, etc) > > they can be built dynamically too. We only provided a version of > g_mass_storage in order to avoid regressions. We can't simply remove that > driver from the kernel. > > > All functions will be supported by configfs in future, and current > > driver will be deleted? > > I don't think we will be able to delete legacy drivers, but they're all > supported through configfs. I guess only webcam is missing. > > > - If yes, how to cover the user who still use the old file system? > > - If no, which binding way for udc and gadget driver will be used? > > going forward, we want to stick with configfs. >
ok, then, what's the plan for current bug for legacy gadget driver (eg, we can't load gadget driver before udc is ready)? I know this bug is existed from 3.10, we may need to at least 1 year for switch to configfs, it includes lots of user habit problems. The user will complaint this problem for more than 2 years. If you think we should fix this bug before we totally switch to configfs, I will continue to enhancement my gadget bus implementation, and let it support configfs and legacy gadget driver well. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
