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? > 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? > -- > BR's > Krzysztof Opasiak 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
