> -----Original Message----- > From: Sebastian Andrzej Siewior [mailto:bigeasy@xxxxxxxxxxxxx] > Sent: Friday, October 17, 2014 3:03 PM > To: Krzysztof Opasiak > Cc: Andrzej Pietrasiewicz; Marek Szyprowski; Greg Kroah-Hartman; > Krzysztof Opasiak; 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-07-17 10:32:36 [+0200], Krzysztof Opasiak wrote: > > In my opinion the target client is not libusbg but a layer above > it, > > let's call it gadget tool and gadget daemon. Libusbg should > provide > > convenient API for all functions which has been merged to kernel. > > Library doesn't need to know which functions are available, it > only > > need to know how to configure them if the are available. If some > > function is not available usbg_create_function() will simply fail > with > > suitable error code. > > 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. 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. > > The problem is in a tool or a daemon. User should be able to > discover > > set of available functions using gadget tool or daemon. Currently > it > > is possible only by iterating through all supported in libusbg > > functions and trying to create each of it. It's not a good > method. In > > my opinion it's more a hack that a solution. > > > > There is a method to discover list of functions which are > compiled as > > kernel modules but without access to kernel config, tool and a > daemon > > are unable to discover which USB functions has been compiled into > > kernel. > > I asked how target solving this. You are refering to libusbg and I > have > no idea what this is. The way I see it, is that you have a bunch of > different > functions and each function is different and needs to be configured > differently. Say storage needs iSerial not to mention the backend > and ncm > needs a MAC address. Where do you gather that information from? > > What I could image is right now is a tool that has a configuration > file which > provides all the information how to configure a function. And now I > ask > myself what is target doing. Does it query which modules and so > backends > / fabrics are available or does it just assume that all of those > are > available? 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. -- 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
