On Sat, 2 Apr 2016, Michal Nazarewicz wrote: > > I'm not so sure about this. Earlier I was undecided about what to do > > if there are multiple mass-storage interfaces in the same config, but > > now I realize that one thread won't work in that situation. The > > difficulty is exception handling. If an error occurs in one of the > > interfaces, it shouldn't affect the others -- but with only one thread > > you can't make that work. > > > > I don't know the details of how the composite core works (I don't even > > remember the difference between a usb_function and > > a usb_function_instance). > > configfs made things quite confusing, yes. IIRC, usb_function roughly > corresponds to an interface while usb_function_instance corresponds to > a module/function driver, except you can easily create multiple > instances. That sounds right. I vaguely remember when I did look at this stuff years ago, the names were backward -- usb_function refers to an instance while usb_function_instance refers to a driver (which obviously doesn't have instances). > > Suppose there are several interfaces in one config, each bound to the > > mass-storage driver. Then won't the driver's bind routine get called > > several times whenever the config is installed? > > > > If so, then each of those calls should create a new thread. There's no > > need to check if the thread has already been started. > > > > If not, then there's no way to use f_mass_storage on multiple > > interfaces in a single config. The driver should refuse to run on > > more than one interface at a time. > > Right, but that’s not what is happening. We have a situation where > single mass storage instance is bound to two interfaces on two different > configs: > > mkdir functions/mass_storage.0 > echo $file > functions/mass_storage.0/lun.0/file > ln -s functions/mass_storage.0 configs/c.1 > ln -s functions/mass_storage.0 configs/c.2 > > configfs doesn’t even allows to express situation where a single > instance of a function is bound to multiple interfaces in a single > configuration (IIRC). That doesn't matter for our purposes now. > At the same time, mass storage should work fine if it’s bound to > multiple configurations. Only one configuration can be active at any > given time so interfaces on different configurations cannot interfere > with each other. Yes, it _should_. But it doesn't with the nokia legacy driver. I don't know if this has any connection with configfs; it could be a problem with the way f_mass_storage interacts with the composite core. > The problem we are having is that when mass storage is added to > a configuration, fsg_bind is called and it starts the thread. This is what I'm not sure about. Which callbacks does the composite core invoke when a config is installed or uninstalled? Those callbacks should be where the thread is started and stopped. > If someone wanted to have two mass storage interfaces on a single > configuration they would have to create two mass storage instances and > each instance has it’s own fsg_common struct (see fsg_alloc_inst > function). > > PS. It seems that legacy/multi is broken because it calls > fsg_common_run_thread twice. Perhaps because f_mass_storage calls fsg_common_run_thread from the wrong place. Alan Stern -- 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
