* Andrzej Pietrasiewicz | 2012-11-22 13:06:54 [+0100]: >My intention is not to add new gadgets, but to promote the use of >usb function modules, e.g. f_mass_storage.ko. finally. >I don't use the usbf_option stuff, though, for the reasons I would >like to state below. Good. In the meantime we decided to drop usbf_option. >The mass storage function requires a hierarchy of subdirectories, >not just one directory in configfs. With usbf_opt there is no Yes, we will have native configfs interface. The tcm gadget uses configfs already for its lun setup. >During its lifetime, the mass storage can require creating >lunX directories for its luns. And again, with usbf_option You have first to detach the gadget because you can't update while it is in progress connected / working. If you add an additional LUN then there is no way to notify the host side about this. >All in all, I think it is better not to force complete separation >of functions from their configfs parts. Instead, I propose >to extend the struct usb_function with 2 operations and extend >the functions with a configfs part dedicated to them. Yes, good. >I also show how to write an adapter module, which provides >the old sysfs-based interface to mass storage with module parameters, >but internally operates on configfs. There is no sysfs interface, is there? We have only modprobe interface. >The patches 03 throuth 12 are not squashed in order to show the >steps involved in porting mass storage to the new framework, >but, ATTENTION, this means that if only some of them are applied, >the code may or may not compile. The patches may need checkpach. k. Sebastian -- 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
