Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
* Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]: Main difference is that each loaded fabric module provides its own directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that each loaded or built-in module has there it own directory. So I assumed they don't do and I don't recall this by the time I want through the code. But if they really do this (as in code of current git) why not stick to the same way instead of hacking a procfs/sysfs interface? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On Wed, Nov 05, 2014 at 11:18:12PM +0100, Sebastian Andrzej Siewior wrote: * Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]: Main difference is that each loaded fabric module provides its own directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that each loaded or built-in module has there it own directory. So I assumed they don't do and I don't recall this by the time I want through the code. But if they really do this (as in code of current git) why not stick to the same way instead of hacking a procfs/sysfs interface? The problem is that we would now have userland ABI problems, unless we have a way of providing backwards compatibility. We would also need patches to libusbg making sure it works with both old and new ways. Without that, we can't move forward :-s -- balbi signature.asc Description: Digital signature
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message- From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc] Sent: Saturday, October 25, 2014 3:07 PM To: Krzysztof Opasiak Cc: 'Sebastian Andrzej Siewior'; 'Krzysztof Opasiak'; Andrzej Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman'; ba...@ti.com; matt.por...@linaro.org; linux-usb@vger.kernel.org Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions On 2014-10-21 11:53:38 [+0200], Krzysztof Opasiak wrote: I don't know the target and it's configfs usage so I can only speak about composing gadget. Assuming that all usb functions are available And thatis why I told you to look at it instead re-inventing the wheel. in kernel is not a good idea. This hurts user experience because a tool or something may tell user that such function is available when really it's not. This means that creating it's instance will fail. Functions are kind of building blocks and gadget is simply some building which consist of that blocks. Those blocks are identified using some unique ID called function type which is just a string registered by kernel driver. Our assumption is that user know exactly how to configure RNDIS, Function FS and other functions. Problem is that user doesn't know which of those functions are available in his current kernel and what are the magic strings registered as a type name. This is exactly the same thing that target does. So again: how does target solve this things? Problem is on two levels: - bare command line interface level User doesn't have any additional tool and only know what is the convention and what is Remote Network Driver Interface Specification and what is Function FS and how to use them. So now I ask how user can discover that first of them is registered as rndis and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that function fs has not been selected while building this kernel and it's not available. So how should we discover it? Just try to create the directory? This is good for one function but what if we have 10 or 15 of them? There has to be a user land tool similar to what target does and the details should be abstracted away. - tool or library level While creating such thing we may hardcode the strings for each currently mainlined function and information how to configure it. The case here is that usually currently running kernel will have only subset of those functions but not all of them. The question here is how user can ask such a tool what he can create? Showing user a full list of known function may be confusing because on one hand we show that this functions is available but on other hand we tell him that we cannot create such function because there is no suitable module. Of course tool can iterate over all known usb functions and try to create each of them to check if this function is available. Don't you thing that this is a little bit weird and confusing? It look really ugly, cause overhead and makes configfs dirty due to creating some test gadget to check available functions. I would assume that to some degree the user knows what he does. And I never said to probe for everything and I don't want to see this. Just show _everything_ that is available in the kernel. The help button can say which kernel module is required. As I said earlier, you need to know the function in order configure it properly. Many things are the same but some may be different. You can compose the gadget within the tool. Once it is complete you can go ahead start playing with configfs. If something fails, you know what you were doing so you can point out a missing module (if this is what you expect). You could even create a /bin/sh script so the target does not need to have the complete tool around. An example: you can install btrfs-tools, UDF, … even without the kernel support for it. You can create a file-system on a file, check a file system and so on. The worst think that can happen is that mount complains. Or (another one) losetup complains that something is not right because loop isn't loaded. Just to sum up: please look how target is dealing with things and do something equivalent. I don't recall that they have a list in kernel of all available backends or fabrics. I have just run through the target ConfigFS interface description on wiki[1]. As far as I understand, those interfaces are not the same and issue which we discuss here is not a case in target. Let me clarify: Main difference is that each loaded fabric module provides its own directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that each loaded or built-in module has there it own directory. That's why you don't need any other place to check what has been compiled-in your kernel or loaded using insmod. You can execute ls and you will get the list of known fabrics. Moreover you
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On 2014-10-21 11:53:38 [+0200], Krzysztof Opasiak wrote: I don't know the target and it's configfs usage so I can only speak about composing gadget. Assuming that all usb functions are available And thatis why I told you to look at it instead re-inventing the wheel. in kernel is not a good idea. This hurts user experience because a tool or something may tell user that such function is available when really it's not. This means that creating it's instance will fail. Functions are kind of building blocks and gadget is simply some building which consist of that blocks. Those blocks are identified using some unique ID called function type which is just a string registered by kernel driver. Our assumption is that user know exactly how to configure RNDIS, Function FS and other functions. Problem is that user doesn't know which of those functions are available in his current kernel and what are the magic strings registered as a type name. This is exactly the same thing that target does. So again: how does target solve this things? Problem is on two levels: - bare command line interface level User doesn't have any additional tool and only know what is the convention and what is Remote Network Driver Interface Specification and what is Function FS and how to use them. So now I ask how user can discover that first of them is registered as rndis and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that function fs has not been selected while building this kernel and it's not available. So how should we discover it? Just try to create the directory? This is good for one function but what if we have 10 or 15 of them? There has to be a user land tool similar to what target does and the details should be abstracted away. - tool or library level While creating such thing we may hardcode the strings for each currently mainlined function and information how to configure it. The case here is that usually currently running kernel will have only subset of those functions but not all of them. The question here is how user can ask such a tool what he can create? Showing user a full list of known function may be confusing because on one hand we show that this functions is available but on other hand we tell him that we cannot create such function because there is no suitable module. Of course tool can iterate over all known usb functions and try to create each of them to check if this function is available. Don't you thing that this is a little bit weird and confusing? It look really ugly, cause overhead and makes configfs dirty due to creating some test gadget to check available functions. I would assume that to some degree the user knows what he does. And I never said to probe for everything and I don't want to see this. Just show _everything_ that is available in the kernel. The help button can say which kernel module is required. As I said earlier, you need to know the function in order configure it properly. Many things are the same but some may be different. You can compose the gadget within the tool. Once it is complete you can go ahead start playing with configfs. If something fails, you know what you were doing so you can point out a missing module (if this is what you expect). You could even create a /bin/sh script so the target does not need to have the complete tool around. An example: you can install btrfs-tools, UDF, … even without the kernel support for it. You can create a file-system on a file, check a file system and so on. The worst think that can happen is that mount complains. Or (another one) losetup complains that something is not right because loop isn't loaded. Just to sum up: please look how target is dealing with things and do something equivalent. I don't recall that they have a list in kernel of all available backends or fabrics. Krzysiek Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message- From: 'Sebastian Andrzej Siewior' [mailto:sebast...@breakpoint.cc] Sent: Monday, October 20, 2014 7:38 PM To: Krzysztof Opasiak Cc: 'Krzysztof Opasiak'; Andrzej Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman'; ba...@ti.com; 'Sebastian Andrzej Siewior'; matt.por...@linaro.org; linux-usb@vger.kernel.org Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote: 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. okay. I try it once again and I am close to give up: target uses configfs in a very similar fashion compared to what the gadget interface does. Similar to the gadget interface it provides different fabrics and back-ends. I doubt there is a list of available functionality exported somewhere in the target code. I believe very much that the userland hides all that information from you and simply assumes that the modules is available (and the kernel tries to load it if is not available but that is an implementation detail whether the kernel or that tool tries to load the module on failure). I don't know the target and it's configfs usage so I can only speak about composing gadget. Assuming that all usb functions are available in kernel is not a good idea. This hurts user experience because a tool or something may tell user that such function is available when really it's not. This means that creating it's instance will fail. Functions are kind of building blocks and gadget is simply some building which consist of that blocks. Those blocks are identified using some unique ID called function type which is just a string registered by kernel driver. Our assumption is that user know exactly how to configure RNDIS, Function FS and other functions. Problem is that user doesn't know which of those functions are available in his current kernel and what are the magic strings registered as a type name. Problem is on two levels: - bare command line interface level User doesn't have any additional tool and only know what is the convention and what is Remote Network Driver Interface Specification and what is Function FS and how to use them. So now I ask how user can discover that first of them is registered as rndis and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that function fs has not been selected while building this kernel and it's not available. So how should we discover it? Just try to create the directory? This is good for one function but what if we have 10 or 15 of them? - tool or library level While creating such thing we may hardcode the strings for each currently mainlined function and information how to configure it. The case here is that usually currently running kernel will have only subset of those functions but not all of them. The question here is how user can ask such a tool what he can create? Showing user a full list of known function may be confusing because on one hand we show that this functions is available but on other hand we tell him that we cannot create such function because there is no suitable module. Of course tool can iterate over all known usb functions and try to create each of them to check if this function is available. Don't you thing that this is a little bit weird and confusing? It look really ugly, cause overhead and makes configfs dirty due to creating some test gadget to check available functions. 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. That is the wrong attempt. You have to have a config file in your userland tool which provides the information of all available functions and how / what is required to configure them. If the user decides to use the storage function the tool will offer the two storage functions we have _or_ display a list of all available functions including a hint/help text what the function what it is good for (or do
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote: 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. okay. I try it once again and I am close to give up: target uses configfs in a very similar fashion compared to what the gadget interface does. Similar to the gadget interface it provides different fabrics and back-ends. I doubt there is a list of available functionality exported somewhere in the target code. I believe very much that the userland hides all that information from you and simply assumes that the modules is available (and the kernel tries to load it if is not available but that is an implementation detail whether the kernel or that tool tries to load the module on failure). 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. That is the wrong attempt. You have to have a config file in your userland tool which provides the information of all available functions and how / what is required to configure them. If the user decides to use the storage function the tool will offer the two storage functions we have _or_ display a list of all available functions including a hint/help text what the function what it is good for (or do you know what ECM, NCM and ACM is good for?). Either way, the user selects the function he/she wants to use and the tool does magic in the background. If the mkdir fails then it is likely that the module is not available and not built-in. And now you can display an error message about missing modules. Seriously I don't see how a list of available / loaded functions will help you in the long run because (as I wrote earlier) you need specific knowledge how to configure it. Btw, what do you do if a given function is not listed? Do you tell the use load the module or you modprobe it? Once it is ready and you have your complete gadget configured you could safe it for later usage. A nice thing would be to export the configuration as a simple sh file which configures the gadget (say the userland is written in java and you would prefer not to install java on your embedded system for a few mkdir/ln/… invocations). 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. Yes and the user land tool I wrote and wrote about should have the required knowledge so you do not have to study the kernel source at all. So if you would have taken a look on target-cli you would see that you do not need to read the kernel code in order to setup scsi device. And exactly the same thing I have in mind for the gadget interface. -- Krzysiek Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message- From: Sebastian Andrzej Siewior [mailto:bige...@breakpoint.cc] Sent: Friday, October 17, 2014 3:03 PM To: Krzysztof Opasiak Cc: Andrzej Pietrasiewicz; Marek Szyprowski; Greg Kroah-Hartman; Krzysztof Opasiak; ba...@ti.com; Sebastian Andrzej Siewior; matt.por...@linaro.org; linux-usb@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] 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'; ba...@ti.com; 'Sebastian Andrzej Siewior'; matt.por...@linaro.org; linux-usb@vger.kernel.org Subject: RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions -Original Message- From: Sebastian Andrzej Siewior [mailto:bige...@breakpoint.cc] Sent: Friday, October 17, 2014 3:03 PM To: Krzysztof Opasiak Cc: Andrzej Pietrasiewicz; Marek Szyprowski; Greg Kroah-Hartman; Krzysztof Opasiak; ba...@ti.com; Sebastian Andrzej Siewior; matt.por...@linaro.org; linux-usb@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
W dniu 16.07.2014 16:45, Felipe Balbi pisze: On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote: On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote: snip 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. I don't have a strong opinion here, either. It is libusbg (that's how the library is actually called now) that should now. The thing is _how_ it should know: it can either be given a config file, or discover what's available. I believe we should take the best from both worlds: - there is a config file distributed with libusbg, - there is some generic way to handle functions not known at the moment of library's release @Krzysztof: @Matt: what do you think? AP -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
17 lip 2014 09:13 Andrzej Pietrasiewicz andrze...@samsung.com napisał(a): W dniu 16.07.2014 16:45, Felipe Balbi pisze: On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote: On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote: snip 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. I don't have a strong opinion here, either. It is libusbg (that's how the library is actually called now) that should now. The thing is _how_ it should know: it can either be given a config file, or discover what's available. I believe we should take the best from both worlds: - there is a config file distributed with libusbg, - there is some generic way to handle functions not known at the moment of library's release @Krzysztof: @Matt: what do you think? 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. 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. -- BR's Krzysztof Opasiak -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
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 signature.asc Description: Digital signature
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
W dniu 11.07.2014 15:22, Sebastian Andrzej Siewior pisze: On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote: another class ? Please don't, we already have the udc class, we could find a way to just use that instead. Using udc clas is not a good idea. This may cause failures in userspace. failures? like what? How would you like to tell that this is not really a udc? Only type of Adding a new class for one file does not look right. Try to add a file if you have to but without creating a new class for it. It looks like it would fit best in the configfs root directory. I guess you mean: $ mount -t configfs none $CONFIGFS_ROOT $ ls $CONFIGFS_ROOT/usb_gadget func_list However, I am not sure this is required at all. I would rather prefer having a userland tool (like target has) which helps you assembling a gadget instead of having users poking at files and then eh look! lets see what this can do…. 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? AP -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
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? AP Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote: another class ? Please don't, we already have the udc class, we could find a way to just use that instead. Using udc clas is not a good idea. This may cause failures in userspace. failures? like what? How would you like to tell that this is not really a udc? Only type of Adding a new class for one file does not look right. Try to add a file if you have to but without creating a new class for it. It looks like it would fit best in the configfs root directory. However, I am not sure this is required at all. I would rather prefer having a userland tool (like target has) which helps you assembling a gadget instead of having users poking at files and then eh look! lets see what this can do…. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On Thu, Jul 10, 2014 at 12:30:59PM +0200, Andrzej Pietrasiewicz wrote:
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.
This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
This time there should be no obvious mistakes: potential
buffer overrun is checked and THIS_MODULE is not dereferenced at all.
Tested with libcomposite compiled-in and modular.
v1..v2:
- changed the location in sysfs: usb_gadget class is added
drivers/usb/gadget/configfs.c | 25 +
drivers/usb/gadget/functions.c | 25 +
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 52 insertions(+)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..358242a 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,37 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);
+static ssize_t gadget_func_list_show(struct class *c,
+ struct class_attribute *a, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct class_attribute usb_gadget_attrs[] = {
+ __ATTR(func_list, S_IRUGO, gadget_func_list_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class usb_gadget_class = {
another class ? Please don't, we already have the udc class, we could
find a way to just use that instead.
--
balbi
signature.asc
Description: Digital signature
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Thursday, July 10, 2014 3:39 PM
To: Andrzej Pietrasiewicz
Cc: linux-usb@vger.kernel.org; Felipe Balbi; Greg Kroah-Hartman;
Sebastian Andrzej Siewior; Marek Szyprowski
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
(...)
+static ssize_t gadget_func_list_show(struct class *c,
+struct class_attribute *a, char
*buf)
{
+ return usb_function_list_functions(buf, PAGE_SIZE); }
+
+static struct class_attribute usb_gadget_attrs[] = {
+ __ATTR(func_list, S_IRUGO, gadget_func_list_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class usb_gadget_class = {
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.
Using udc clas is not a good idea. This may cause failures in userspace.
How would you like to tell that this is not really a udc? Only type of
file will be different than for the udcs (udcs are symlink and this
would be normal file or directory). But who knows how much scripts or
soft depends on assumption that /sys/class/udc contains only names of
udc available in system?
Libusbg is good example. When you pass NULL as udc name to
usbg_enable_gadget() method, it scandir() the /sys/class/udc and take
the first entry of this directory. If we add something what is not an
udc this library and potentially many other userspace apps behavior will
be changed and they may suddenly fail.
I know that this solution has some disadvantages but I don't see any
better one which wont destroy the userspace. Maybe you have some idea?
Please share it with us:) Please let me also recall v1 version of this
patch which has been changed because it fails when libcomposite is built
into kernel (it hasn't own directory in /sys/module so adding an
attribute causes NULL pointer dereference)
--
BR's
Krzysztof Opasiak
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
