On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote: > W dniu 14.07.2014 11:50, Sebastian Andrzej Siewior pisze: >> On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote: >>> A userland tool for assembling gadgets with configfs needs to know what >>> it can or cannot do, that is, what usb functions are available. >>> Knowing what functions there are is not the same thing as being able >>> to discover it, so in fact this looks like a philosophical issue: >>> whether userspace should be able to discover what usb functions >>> there are or not? >> >> The same problem has target in principle as it supports more than one >> backend / protocol, etc. What does it do? >> > > I believe a part of your response is missing, the above is all I got. No, it was complete. It has been compressed due to lack of time, true. You say that userland tool may or may not need to know which functions are available. And this is as you say a "philosophical issue". Correct. Either your userland has a list of all available functions (with help / explanation what it is and what it is good for) or it grabs a list of available functions. The latter has the advantage that you can use functions which were introduced into the kernel before the userland tool was updated (unless you can specify a "custom" function name). The former has the advantage that you can "select" say a serial function without knowing that you have to deal with f_acm. So I think it boils down to how educated is the user of this in the end. If he knows that he needs f_acm he does not need a list. If he tries to use f_acm "manually" and the loading/linking the function fails with ENOENT plus the kernel says "dude that function is not available" then he knows that something is missing. Either that module has not been copied or it has not been enabled in the kernel. That is why I suggested to look at target subsystem and its userland tool for configuration. In target you can have multiple storage units (say file, block device, ram disk, transparent SCSI) and a few protocols to access the device (iSCSI, firewire, USB, …). So you have the same problem from the user/tool point of view: May or may I not use the iSCSI protocol? Was it enabled in the kernel? What modules are available at all? Since target and its userland tool (targetcli) is available for sometime now, maybe a look on those will give an idea on how the problem has been solved once _and_ whether it is good or not. > > AP > 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
