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. > 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
