On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote: > > So you didn't answer my questions. Say you have a list of two > > functions > > says acm and ncm. Based on this information how do you know how to > > configure it? > > > > That's a good question but not directly related to current problem. > The problem is that user ends up in empty functions directory in > some gadget and has to write some magic strings which he may not know. > He has just build in the usb_f_mass_storage module and usb_f_ss_lb > and where should he get the information that he needs to use > mass_storage, Loopback and SourceSink as function types? > All those three are just magic strings hardcoded in kernel and not > exported in any place to userspace but we enforce the user to know them > and provide them to configfs. okay. I try it once again and I am close to give up: target uses configfs in a very similar fashion compared to what the gadget interface does. Similar to the gadget interface it provides different fabrics and back-ends. I doubt there is a list of available "functionality" exported somewhere in the target code. I believe very much that the userland hides all that information from you and simply assumes that the modules is available (and the kernel tries to load it if is not available but that is an implementation detail whether the kernel or that tool tries to load the module on failure). > Second scenario is that we have some running kernel and everything is > compiled-in and we would like to create a gadget. Let's say that we have > experience and we know all that magic strings but there still is a > problem > because we don't know what is available in current kernel. We need to > try > creating instance for all known for us functions type to learn what is > available in this kernel. That is the wrong attempt. You have to have a config file in your userland tool which provides the information of all available functions and how / what is required to configure them. If the user decides to use the storage function the tool will offer the two storage functions we have _or_ display a list of all available functions including a hint/help text what the function what it is good for (or do you know what ECM, NCM and ACM is good for?). Either way, the user selects the function he/she wants to use and the tool does magic in the background. If the mkdir fails then it is likely that the module is not available and not built-in. And now you can display an error message about missing modules. Seriously I don't see how a list of available / loaded functions will help you in the long run because (as I wrote earlier) you need specific knowledge how to configure it. Btw, what do you do if a given function is not listed? Do you tell the use load the module or you modprobe it? Once it is ready and you have your complete gadget configured you could safe it for later usage. A nice thing would be to export the configuration as a simple sh file which configures the gadget (say the userland is written in java and you would prefer not to install java on your embedded system for a few mkdir/ln/… invocations). > Library may support all currently mainlined functions and know how to > configure them. Like I wrote above problem is that currently running > kernel may have only subset of them and user has no ability to get > list of functions from kernel. Even if he has a config file he needs > to study kernel source to know what name has this particular module > registered in configfs. Yes and the user land tool I wrote and wrote about should have the required knowledge so you do not have to study the kernel source at all. So if you would have taken a look on target-cli you would see that you do not need to read the kernel code in order to setup scsi device. And exactly the same thing I have in mind for the gadget interface. > > -- > Krzysiek > 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
