> -----Original Message----- > From: Sebastian Andrzej Siewior [mailto:sebastian@xxxxxxxxxxxxx] > Sent: Saturday, October 25, 2014 3:07 PM > To: Krzysztof Opasiak > Cc: 'Sebastian Andrzej Siewior'; 'Krzysztof Opasiak'; Andrzej > Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman'; > balbi@xxxxxx; matt.porter@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of > available functions > > On 2014-10-21 11:53:38 [+0200], Krzysztof Opasiak wrote: > > 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 > > And thatis why I told you to look at it instead re-inventing the > wheel. > > > 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. > > This is exactly the same thing that target does. So again: how does > target solve this things? > > > 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? > > There has to be a user land tool similar to what target does and > the > details should be abstracted away. > > > - 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. > > I would assume that to some degree the user knows what he does. And > I > never said to probe for everything and I don't want to see this. > Just > show _everything_ that is available in the kernel. The help button > can > say which kernel module is required. As I said earlier, you need to > know > the function in order configure it properly. Many things are the > same > but some may be different. > You can compose the gadget within the tool. Once it is complete you > can go > ahead start playing with configfs. If something fails, you know > what you > were doing so you can point out a missing module (if this is what > you expect). > You could even create a /bin/sh script so the target does not need > to > have the complete tool around. > > An example: you can install btrfs-tools, UDF, … even without the > kernel > support for it. You can create a file-system on a file, check a > file system > and so on. The worst think that can happen is that mount complains. > Or > (another one) losetup complains that something is not right because > "loop" > isn't loaded. > > Just to sum up: please look how target is dealing with things and > do > something equivalent. I don't recall that they have a list in > kernel of > all available backends or fabrics. I have just run through the target ConfigFS interface description on wiki[1]. As far as I understand, those interfaces are not the same and issue which we discuss here is not a case in target. Let me clarify: Main difference is that each loaded fabric module provides its own directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that each loaded or built-in module has there it own directory. That's why you don't need any other place to check what has been compiled-in your kernel or loaded using insmod. You can execute ls and you will get the list of known fabrics. Moreover you can create there a directory target will try to load suitable module if it has not been already registered in target framework. Now let's go to usb gadget. Our root directory is empty by default. First of all you have to create gadget and then cd to functions dir Which is always empty for new gadget. We don't have any place where You cannot run ls or something to get the list of register function Types because to don't have separate entries for function types but only for function instances. So summing up, this problem is solved in target by providing top-level directory for each fabrics module. Each module has a set of attributes which are used by client while device configuration. In usb gadget, top-level dirs are assumed to be gadget and all entries in functions subdir in gadget are considered to be function instances not function types. Footnotes: 1 - http://linux-iscsi.org/wiki/ConfigFS#Layout -- 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
