> -----Original Message----- > From: 'Sebastian Andrzej Siewior' [mailto:sebastian@xxxxxxxxxxxxx] > Sent: Monday, October 20, 2014 7:38 PM > To: Krzysztof Opasiak > Cc: 'Krzysztof Opasiak'; Andrzej Pietrasiewicz; Marek Szyprowski; > 'Greg Kroah-Hartman'; balbi@xxxxxx; 'Sebastian Andrzej Siewior'; > matt.porter@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of > available functions > > 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). I don't know the target and it's configfs usage so I can only speak about composing gadget. Assuming that all usb functions are available in kernel is not a good idea. This hurts user experience because a tool or something may tell user that such function is available when really it's not. This means that creating it's instance will fail. Functions are kind of building blocks and gadget is simply some building which consist of that blocks. Those blocks are identified using some unique ID called "function type" which is just a string registered by kernel driver. Our assumption is that user know exactly how to configure RNDIS, Function FS and other functions. Problem is that user doesn't know which of those functions are available in his current kernel and what are the magic strings registered as a type name. Problem is on two levels: - bare command line interface level User doesn't have any additional tool and only know what is the convention and what is Remote Network Driver Interface Specification and what is Function FS and how to use them. So now I ask how user can discover that first of them is registered as rndis and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that function fs has not been selected while building this kernel and it's not available. So how should we discover it? Just try to create the directory? This is good for one function but what if we have 10 or 15 of them? - tool or library level While creating such thing we may hardcode the strings for each currently mainlined function and information how to configure it. The case here is that usually currently running kernel will have only subset of those functions but not all of them. The question here is how user can ask such a tool what he can create? Showing user a full list of known function may be confusing because on one hand we show that this functions is available but on other hand we tell him that we cannot create such function because there is no suitable module. Of course tool can iterate over all known usb functions and try to create each of them to check if this function is available. Don't you thing that this is a little bit weird and confusing? It look really ugly, cause overhead and makes configfs dirty due to creating some "test" gadget to check available functions. > > > 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. But please separate knowledge about how to configure each function from knowledge if this function is currently available. We may know the configuration for each mainlined usb function but our current kernel may have only acm for example. So why should we show user a full list with storage, Ethernet and other if those functions are not available and it won’t be possible to create their instance? It's very confusing for user. Moreover if you would like to say now that we may provide information what is available in config file please wait a minute and ask again yourself if you really would like to use it. Creating a separate configuration file which content depends on current kernel configuration means that something is missing in kernel framework. This is why the whole sys and proc has been created. To allow user look into kernel and learn what hardware and kernel objects are available. Please once again look to example which I gave you (the file systems). We have a generic framework where particular driver can register. While mounting, user can specify -t option and pass the fs type which is the "name of driver" (string which uniquely identify the fs driver ex. ext4, fat32 etc.). But user doesn't need to know those magic strings because they are all available in /proc/filesystems. Don't you think that situation with usb functions is very similar? User should be able to ask kernel "Hey kernel, tell me what you have inside what I can use?" This is how it works with filesystems and what user should be able to do with usb functions. I don't see any reason to write this information manually in regular config file for tool instead of exporting this automatically form kernel. > > 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? Like I wrote above we may know how to configure each mainlined usb functions but we should also have opportunity to discover what we have in our currently running kernel. > > 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). We have chosen other approach in libusbg. We create a configuration file which can be loaded using single library function. > > > 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. Please see my comments above. Krzysiek -- 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
