The patchset introduces a File-backed Storage Gadget (FSG) converted to use a composite framework. The first patch adds File-backed Storage Function (FSF) which is heavily based on the FSG. The second patch converts FSG to use FSF and composite framework. Moreover, FSF introduces several changes compared to FSG. First of all, the read-only flag, removable and CD-ROM emulation is configured per-LUN basis rather then globally for the whole function. What's however more important is that FSF has been split into two structures: an fsf_common and fsf. At this moment former keeps track of LUNs and the former is FSF instance which stores pointer to fsf_common. Such architecture has been chosen as to make it possible to add several instances of FSF added to several configurations of a single gadget (we are working on a gadget which does that). We have tried mass storage function from Android but it fail to work with two or more configurations. So, if one wants to add FSF to a configuration they first need to create an fsf_common structure (using file_storage_function_init_common() function with configuration specified in fsf_common_config structure) and then use created structure when adding structures to USB configurations (using file_storage_function_add() function). After functions are added, one need to release the fsf_common structure (using file_storage_function_release_common() function) which will decrease it's reference counter (no worries, FSF instances increased it). As creating the fsf_common_config and all of the management may be a bit tedious f_file_storage_params.c introduces various methods which make life easier. This file, adds module parameters and provides file_storage_function_setup() function which creates a fsf_common object -- to reference it one uses file_storage_function_singleton() function. This makes the usage of FSF look more like usage of other functions: first setup, then add and cleanup (expect cleanup can be called in bind function). Now, what's yet to be done is move the kernel thread related data to the fsf_common structure. Currently, when FSF is added to two configurations two kernel threads are created -- only one is active at a time but still, it's not good design. I would appreciate all comments and suggestions. Also, code review would be gladly welcome as well. -- Best regards, _ _ .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał "mina86" Nazarewicz (o o) ooo +-<m.nazarewicz@xxxxxxxxxxx>-<mina86@xxxxxxxxxx>-ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
