| |||||||||||||
The USB composite frameworkThe USB composite frameworkPosted Jul 15, 2010 16:16 UTC (Thu) by jimparis (subscriber, #38647)Parent article: The USB composite framework
I'm finding this article very confusing.
When you say things like "The really hard work is done inside the MSF", it sounds like you're talking about the fsg_* functions, which are separate (but mostly copied) from Alan Stern's FSG? So a function like fsg_main_thread in f_mass_storage.c is part of MSF, but the function fsg_main_thread in file_storage.c is part of FSG?
Having 5 ".c" files #included directly in "the full source code" doesn't help clarify things. Doesn't that also cause symbol conflicts if we wanted to write two modules and install them both?
I guess this article mostly is focused on how to use the composite framework, but the actual implementation of the device (MSF/FSG/whatever) seems to be the more interesting part from a USB driver writer point of view. Does the composite framework make that part any easier?
I'd really look forward to a future article on "more powerful gadgets" as you mention. Particularly interesting would be how such a composite gadget is treated and works on typical operating systems (can each function usually be bound to a driver independently?) and how to deal with hardware limitations (as I understand, most hardware has various limitations on numbers of endpoints or restricts their sizes, etc).
(Log in to post comments)
The USB composite framework Posted Jul 15, 2010 18:38 UTC (Thu) by iabervon (subscriber, #722) [Link] I guess this article mostly is focused on how to use the composite framework, but the actual implementation of the device (MSF/FSG/whatever) seems to be the more interesting part from a USB driver writer point of view. Does the composite framework make that part any easier?My impression is that the framework is not intended to make the interesting part any easier, but rather to make the uninteresting part trivial. Having written a USB gadget (not on Linux), I've found that handling EP0 is a big chunk of uninteresting code that needs to be correct and involves fiddly interactions with your drivers, in that you have to make sure that your driver, your descriptor as sent on EP0, and your hardware registers all agree on how the endpoints are configured, and weird things happen if they don't.
The USB composite framework Posted Jul 25, 2010 11:49 UTC (Sun) by mina86 (subscriber, #68442) [Link]
As I've mentioned, Mass Storage Function is merely a conversion of the File-Storage Gadget so most of the code in MSF is copied with modifications from FSG. As such, your understanding is correct, by MSF I mean all the functions in f_mass_storage.c as well as storage_common.c (the latter is code that is identical (or nearly identical) in both MSF and FSG).
The prefix of the function names may be confusing. At one point I even wanted to use fsg_ for FSG stuff, msf_ for MSF stuff and stor_ for commons but Alan convinced my that it's too much hustle and modification not worth the effort. Hence, the fsg_ prefix stayed.
As far as including .c files... to be honest, I'm not entirely convinced why this is done this way but that's the way it is done in other composite gadget drivers as well. The comment you may find in those is:
> Kbuild is not very cooperative with respect to linking separately compiled library objects into one module. So for now we won't use separate compilation ... ensuring init/exit sections work to shrink the runtime footprint, and giving us at least some parts of what a "gcc --combine ... part1.c part2.c part3.c ... " build would.
Going further in your comment, the situation with composite is just like iabervon described. It makes uninteresting things trivial. I would also add that it makes the more interesting part a bit harder.
This is because composite function has to worry about registering interface and string IDs and never knows in how many configurations it will be present or ever how many configurations gadget has.
One of the most complicated thing about converting File-Storage Gadget to Mass Storage Function was to allow for it to be added to several USB configurations. To achieve that I have created the fsg_common structure with reference counting and some such.
As of next articles I can only thank you for interest and get back to work. ;) Nonetheless, the my next article probably won't cover most of your questions but should be valuable addition to this one.
I may only quickly point out that you deal with hardware limitations by obeying them. :P If your UDC has limited number of endpoints you won't be able to stash many composite functions in a single configuration in your gadget. Mass storage is rather simple since in bulk-only mode (the one implemented by MSF) it uses only one IN and one OUT endpoint but generally functions may need more endpoints.
|
|||||||||||||