On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote: > 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. I agree with Sebastian here. At the end of the day, we don't expect users to go fiddle with configfs directly and rather use libgadget through a tool that uses it. -- balbi
Attachment:
signature.asc
Description: Digital signature
