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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.