Re: usb function framework
Brian Swetland <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Organization | Google, Inc. |
| Message-ID | <20071112203307.GA21473@bulgaria> |
[Greg KH <[email protected]>] > In poking around the newly released "Android" kernel git tree: > http://git.android.com/ > > I noticed that you checked in a rather large "usb function framework" > chunk of code. > > As this is competing directly with the current in-kernel usb gadget > framework, it seems strange to me that you did not come and try to work > with the Linux kernel community about your issues with the current > codebase. Some notes to start with: - prior to the official project announcement we were not publicly talking about the kernel work (or any other part of it) - the function framework is a bit of an experiment and not necessarily where we'll be going long-term. - we're now starting to work with the linux kernel folks to clean stuff up towards getting it to mainline, starting with core MSM7K support (being reviewed on the arm linux kernel list now, etc). > What is wrong with the current gadget framework that resulted in this > rewrite? I'm sure that we would be glad to work with you to prevent > such duplicated effort, especially one that is probably ensured to never > make it into the main kernel tree due to the duplicated functionality. We need to do a lot of varied composite device support, something which (to the best of my understanding of it) gadget does not inherently support. My goal is a nice framework for being able to build individual functions and bolt them together (eventually dynamically) without having to fiddle with the common code. One of the things we're investigating is stacking the "function" business on top of gadget (avoiding replicating the bottom layers of things). We of course have both short term and long term goals here -- short term we need to accomplish things necessary for the platform to ship. Long term we'd like to get as much of our kernel work as possible in line with the mainline. This may mean using something home-grown to take care of immediate needs while the ideal "right for linux mainline" path is figured out. > Confused, > > greg k-h No confusion intended, Brian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel