> -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Krzysztof Opasiak > Sent: Friday, October 17, 2014 4:30 PM > To: 'Sebastian Andrzej Siewior'; 'Krzysztof Opasiak' > Cc: Andrzej Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman'; > balbi@xxxxxx; 'Sebastian Andrzej Siewior'; matt.porter@xxxxxxxxxx; > linux-usb@xxxxxxxxxxxxxxx > Subject: RE: [PATCHv2] usb: gadget: composite: Provide a list of > available functions > > > > > -----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. > In addition, this situation is quite similar to providing implementation of some file system. Instead of looking to config file or going through kernel source or doing anything else you have a list of registered file systems in /proc/filesystems. Don't you think that this situation is very similar to our? -- 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
