Re: [RFC 0/2] USB gadget - configfs
On 08/21/2012 10:19 AM, Andrzej Pietrasiewicz wrote: @Joel: However, I am wondering if it would make sense to get rid of the "connect" (or "ready", if you will) attribute altogether and instead use symlinks: when a user wants to make the gadget ready, they do an ln -s, when they want to unbind the gadget they remove the link. What do you think? I started the "ready" attribue and this symlink sounds reasonable. There is one more thing to it, I believe; it is how to associate udc's with gadgets. Perhaps the most convenient way is not needing to do it explicitly at all: either some udc is found and the gadget is bound to it, I would prefer explicit binding. Right now first one wins which not good. or not. However, I am wondering if something in the spirit of "1984" can happen: all udcs are equal but some udcs are more equal than others? So sometimes the user might be interested in binding their gadget to a particular udc, or at least to a particular kind of udc (no matter which one if there are more than one of its kind). Do you have a use case for this? I have a simple one: A phone with two plugs. You select on the gui storage and network on plug #1 and serial on plug #2. If you want to obey the selection you have to always know which UDC ends up on plug #1 and which on #2. That means the user _always_ wants to bind it to a particular UDC. And the question is, whether we want only explicit association with udc, only implicit association with udc, or both? /usb-gadget/gadgets/g1 /usb-gadget/udcs/udc1 /usb-gadget/udcs/udc2 and now symlink g1 into udc1 and or udc2 g1 is created by the user and can be named however he wants it to be. udc1 can be the device name which is unique as well and always the same thing. It can have a property which distinguish it from udc2 like memory address or something. Andrzej Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, On Monday, August 20, 2012 8:00 AM Joel Becker wrote: > I think what you want here is a symlink. Create a directory high in > the tree called 'ready' or 'available', and when you want to lock the > device in place, symlink it into that directory. This will pin the item. > You can also make use of the ->allow_link() and ->drop_link() callbacks to > prevent symlinking an item until it is fully configured, and prevent > unlinking an item that is in use. > I have a question to you. In fs/configfs/dir.c, in a comment before configfs_depend_item and configfs_depend_prep you say that "configfs uses VFS to handle all locking". I am trying to understand how this works. Could you please elaborate a bit about it? Which locks from VFS handle "all locking"? When does locking happen? Thanks, Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, On Monday, August 20, 2012 8:00 AM Joel Becker wrote: snip I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. I have a question to you. In fs/configfs/dir.c, in a comment before configfs_depend_item and configfs_depend_prep you say that configfs uses VFS to handle all locking. I am trying to understand how this works. Could you please elaborate a bit about it? Which locks from VFS handle all locking? When does locking happen? Thanks, Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/21/2012 10:19 AM, Andrzej Pietrasiewicz wrote: @Joel: However, I am wondering if it would make sense to get rid of the connect (or ready, if you will) attribute altogether and instead use symlinks: when a user wants to make the gadget ready, they do an ln -s, when they want to unbind the gadget they remove the link. What do you think? I started the ready attribue and this symlink sounds reasonable. There is one more thing to it, I believe; it is how to associate udc's with gadgets. Perhaps the most convenient way is not needing to do it explicitly at all: either some udc is found and the gadget is bound to it, I would prefer explicit binding. Right now first one wins which not good. or not. However, I am wondering if something in the spirit of 1984 can happen: all udcs are equal but some udcs are more equal than others? So sometimes the user might be interested in binding their gadget to a particular udc, or at least to a particular kind of udc (no matter which one if there are more than one of its kind). Do you have a use case for this? I have a simple one: A phone with two plugs. You select on the gui storage and network on plug #1 and serial on plug #2. If you want to obey the selection you have to always know which UDC ends up on plug #1 and which on #2. That means the user _always_ wants to bind it to a particular UDC. And the question is, whether we want only explicit association with udc, only implicit association with udc, or both? /usb-gadget/gadgets/g1 /usb-gadget/udcs/udc1 /usb-gadget/udcs/udc2 and now symlink g1 into udc1 and or udc2 g1 is created by the user and can be named however he wants it to be. udc1 can be the device name which is unique as well and always the same thing. It can have a property which distinguish it from udc2 like memory address or something. Andrzej Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Sebastian, On Monday, August 20, 2012 1:01 PM Sebastian Andrzej Siewior wrote > > That would be something like > >$ ln -s /cfg/usb-function-gadget/G1 \ > /cfg/usb-function-gadget/udcs/udc1/ > > Where we "bind" the complete gadget (G1) including the mass storage > configuration to the UDC (udc1 in this example). > As far as I understand it, Joel's intention was only to show how it is possible to prohibit removing some items with rmdir; in this case if a "lun0" is linked to from somewhere else it is not possible to do "rmdir lun0"; this was the purpose of my original question. @Joel: However, I am wondering if it would make sense to get rid of the "connect" (or "ready", if you will) attribute altogether and instead use symlinks: when a user wants to make the gadget ready, they do an ln -s, when they want to unbind the gadget they remove the link. What do you think? There is one more thing to it, I believe; it is how to associate udc's with gadgets. Perhaps the most convenient way is not needing to do it explicitly at all: either some udc is found and the gadget is bound to it, or not. However, I am wondering if something in the spirit of "1984" can happen: all udcs are equal but some udcs are more equal than others? So sometimes the user might be interested in binding their gadget to a particular udc, or at least to a particular kind of udc (no matter which one if there are more than one of its kind). And the question is, whether we want only explicit association with udc, only implicit association with udc, or both? Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Sebastian, On Monday, August 20, 2012 1:01 PM Sebastian Andrzej Siewior wrote snip That would be something like $ ln -s /cfg/usb-function-gadget/G1 \ /cfg/usb-function-gadget/udcs/udc1/ Where we bind the complete gadget (G1) including the mass storage configuration to the UDC (udc1 in this example). As far as I understand it, Joel's intention was only to show how it is possible to prohibit removing some items with rmdir; in this case if a lun0 is linked to from somewhere else it is not possible to do rmdir lun0; this was the purpose of my original question. @Joel: However, I am wondering if it would make sense to get rid of the connect (or ready, if you will) attribute altogether and instead use symlinks: when a user wants to make the gadget ready, they do an ln -s, when they want to unbind the gadget they remove the link. What do you think? There is one more thing to it, I believe; it is how to associate udc's with gadgets. Perhaps the most convenient way is not needing to do it explicitly at all: either some udc is found and the gadget is bound to it, or not. However, I am wondering if something in the spirit of 1984 can happen: all udcs are equal but some udcs are more equal than others? So sometimes the user might be interested in binding their gadget to a particular udc, or at least to a particular kind of udc (no matter which one if there are more than one of its kind). And the question is, whether we want only explicit association with udc, only implicit association with udc, or both? Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Mon, Aug 20, 2012 at 01:01:03PM +0200, Sebastian Andrzej Siewior wrote: > On 08/20/2012 07:59 AM, Joel Becker wrote: > > I think what you want here is a symlink. Create a directory > >high in the tree called 'ready' or 'available', and when you want to > >lock the device in place, symlink it into that directory. This will pin > >the item. You can also make use of the ->allow_link() and ->drop_link() > >callbacks to prevent symlinking an item until it is fully configured, > >and prevent unlinking an item that is in use. > > > > $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ > > /cfg/usb-function-gadget/ready/ > > > >or something like that. > > That would be something like > > $ ln -s /cfg/usb-function-gadget/G1 \ > /cfg/usb-function-gadget/udcs/udc1/ > > Where we "bind" the complete gadget (G1) including the mass storage > configuration to the UDC (udc1 in this example). > > At this point we could snapshot the complete configuration so we have > it persistent and if somebody changes attributes within /cfg/usb- > function-gadget/G1 it doesn't matter because we have the copy. > > Is it _this_ what you want us to do? A snapshot? No, I don't see why you would snapshot. You can, btw, reject ->store_attribute() operations once you are in a "ready" state. That's different from preventing the removal of items. Joel -- The Graham Corollary: The longer a socially-moderated news website exists, the probability of an old Paul Graham link appearing at the top approaches certainty. http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Mon, Aug 20, 2012 at 10:53:42AM +0200, Andrzej Pietrasiewicz wrote: > Hello Joel, > > Thanks for your reply. > > On Monday, August 20, 2012 8:00 AM Joel Becker wrote: > > > > I think what you want here is a symlink. Create a directory > > high in the tree called 'ready' or 'available', and when you want to > > lock the device in place, symlink it into that directory. This will pin > > the item. You can also make use of the ->allow_link() and ->drop_link() > > callbacks to prevent symlinking an item until it is fully configured, > > and prevent unlinking an item that is in use. > > > > $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ > > /cfg/usb-function-gadget/ready/ > > > > Is using the userspace program "ln" the way you suggest doing it? Or just > a suggestion about what should be the link target and the link name? You could use ln, you could use symlink(2), or some other method. The symlink itself is the goal. The names are my best guess at how your system is laid out; it's not meant to pick a name for you. > If links are to be created from userspace then some other process can race > us and rmdir "lun0" before ln is called, can't it? Yes, but that same process can race the write of '1' to "connect" as well, right? I don't see the difference. > And a question to you as the creator of configfs: is using symlinks to > prevent config item deletion their intended purpose? How do you like it? Yes, it is an intended use. Another intended use is simplification of access. For example, if you have all connected things in the "ready" subdirectory, you don't have to go scanning all the "connect" files to find them. Joel -- "I always thought the hardest questions were those I could not answer. Now I know they are the ones I can never ask." - Charlie Watkins http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/20/2012 07:59 AM, Joel Becker wrote: I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the ->allow_link() and ->drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ or something like that. That would be something like $ ln -s /cfg/usb-function-gadget/G1 \ /cfg/usb-function-gadget/udcs/udc1/ Where we "bind" the complete gadget (G1) including the mass storage configuration to the UDC (udc1 in this example). At this point we could snapshot the complete configuration so we have it persistent and if somebody changes attributes within /cfg/usb- function-gadget/G1 it doesn't matter because we have the copy. Is it _this_ what you want us to do? A snapshot? Joel Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, Thanks for your reply. On Monday, August 20, 2012 8:00 AM Joel Becker wrote: > > I think what you want here is a symlink. Create a directory > high in the tree called 'ready' or 'available', and when you want to > lock the device in place, symlink it into that directory. This will pin > the item. You can also make use of the ->allow_link() and ->drop_link() > callbacks to prevent symlinking an item until it is fully configured, > and prevent unlinking an item that is in use. > > $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ > /cfg/usb-function-gadget/ready/ > Is using the userspace program "ln" the way you suggest doing it? Or just a suggestion about what should be the link target and the link name? If links are to be created from userspace then some other process can race us and rmdir "lun0" before ln is called, can't it? And a question to you as the creator of configfs: is using symlinks to prevent config item deletion their intended purpose? How do you like it? Thanks, Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Fri, Aug 17, 2012 at 12:34:11PM +0200, Sebastian Andrzej Siewior wrote: > On 08/17/2012 12:30 PM, Andrzej Pietrasiewicz wrote: > >>There is a separation between "setting myself up" and "seeing that a host > >>wants to talk to me". You are a woman. And if you not done yet done you > >ignore > >>the host until you are ready. Can also be ready before the host wants to > >talk > >>to you. It depends on your mood / use case (give the use the choice > >between > >>storage& network and offer always both because we are self powered). > >> > > > >You never know when she is ready... ;) > > > >Please note, that in the example implementation it is userspace > >who needs to explicitly store "1" into the "connect" attribute; > >if it is not set, connecting the cable will have no effect and, > >conversely, if the cable is connected but the "1" is not stored, > >the gadget will not be seen by the host. > > maybe we should rename "connect" here to "ready" or "available". It > seems to cause confusion. I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the ->allow_link() and ->drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ or something like that. Joel -- "Born under a bad sign. I been down since I began to crawl. If it wasn't for bad luck, I wouldn't have no luck at all." http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Fri, Aug 17, 2012 at 12:34:11PM +0200, Sebastian Andrzej Siewior wrote: On 08/17/2012 12:30 PM, Andrzej Pietrasiewicz wrote: There is a separation between setting myself up and seeing that a host wants to talk to me. You are a woman. And if you not done yet done you ignore the host until you are ready. Can also be ready before the host wants to talk to you. It depends on your mood / use case (give the use the choice between storage network and offer always both because we are self powered). You never know when she is ready... ;) Please note, that in the example implementation it is userspace who needs to explicitly store 1 into the connect attribute; if it is not set, connecting the cable will have no effect and, conversely, if the cable is connected but the 1 is not stored, the gadget will not be seen by the host. maybe we should rename connect here to ready or available. It seems to cause confusion. I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ or something like that. Joel -- Born under a bad sign. I been down since I began to crawl. If it wasn't for bad luck, I wouldn't have no luck at all. http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, Thanks for your reply. On Monday, August 20, 2012 8:00 AM Joel Becker wrote: I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ Is using the userspace program ln the way you suggest doing it? Or just a suggestion about what should be the link target and the link name? If links are to be created from userspace then some other process can race us and rmdir lun0 before ln is called, can't it? And a question to you as the creator of configfs: is using symlinks to prevent config item deletion their intended purpose? How do you like it? Thanks, Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/20/2012 07:59 AM, Joel Becker wrote: I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ or something like that. That would be something like $ ln -s /cfg/usb-function-gadget/G1 \ /cfg/usb-function-gadget/udcs/udc1/ Where we bind the complete gadget (G1) including the mass storage configuration to the UDC (udc1 in this example). At this point we could snapshot the complete configuration so we have it persistent and if somebody changes attributes within /cfg/usb- function-gadget/G1 it doesn't matter because we have the copy. Is it _this_ what you want us to do? A snapshot? Joel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Mon, Aug 20, 2012 at 10:53:42AM +0200, Andrzej Pietrasiewicz wrote: Hello Joel, Thanks for your reply. On Monday, August 20, 2012 8:00 AM Joel Becker wrote: I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ Is using the userspace program ln the way you suggest doing it? Or just a suggestion about what should be the link target and the link name? You could use ln, you could use symlink(2), or some other method. The symlink itself is the goal. The names are my best guess at how your system is laid out; it's not meant to pick a name for you. If links are to be created from userspace then some other process can race us and rmdir lun0 before ln is called, can't it? Yes, but that same process can race the write of '1' to connect as well, right? I don't see the difference. And a question to you as the creator of configfs: is using symlinks to prevent config item deletion their intended purpose? How do you like it? Yes, it is an intended use. Another intended use is simplification of access. For example, if you have all connected things in the ready subdirectory, you don't have to go scanning all the connect files to find them. Joel -- I always thought the hardest questions were those I could not answer. Now I know they are the ones I can never ask. - Charlie Watkins http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Mon, Aug 20, 2012 at 01:01:03PM +0200, Sebastian Andrzej Siewior wrote: On 08/20/2012 07:59 AM, Joel Becker wrote: I think what you want here is a symlink. Create a directory high in the tree called 'ready' or 'available', and when you want to lock the device in place, symlink it into that directory. This will pin the item. You can also make use of the -allow_link() and -drop_link() callbacks to prevent symlinking an item until it is fully configured, and prevent unlinking an item that is in use. $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \ /cfg/usb-function-gadget/ready/ or something like that. That would be something like $ ln -s /cfg/usb-function-gadget/G1 \ /cfg/usb-function-gadget/udcs/udc1/ Where we bind the complete gadget (G1) including the mass storage configuration to the UDC (udc1 in this example). At this point we could snapshot the complete configuration so we have it persistent and if somebody changes attributes within /cfg/usb- function-gadget/G1 it doesn't matter because we have the copy. Is it _this_ what you want us to do? A snapshot? No, I don't see why you would snapshot. You can, btw, reject -store_attribute() operations once you are in a ready state. That's different from preventing the removal of items. Joel -- The Graham Corollary: The longer a socially-moderated news website exists, the probability of an old Paul Graham link appearing at the top approaches certainty. http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/17/2012 12:30 PM, Andrzej Pietrasiewicz wrote: There is a separation between "setting myself up" and "seeing that a host wants to talk to me". You are a woman. And if you not done yet done you ignore the host until you are ready. Can also be ready before the host wants to talk to you. It depends on your mood / use case (give the use the choice between storage& network and offer always both because we are self powered). You never know when she is ready... ;) Please note, that in the example implementation it is userspace who needs to explicitly store "1" into the "connect" attribute; if it is not set, connecting the cable will have no effect and, conversely, if the cable is connected but the "1" is not stored, the gadget will not be seen by the host. maybe we should rename "connect" here to "ready" or "available". It seems to cause confusion. Andrzej Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Sebastian, Hello Joel, On Friday, August 17, 2012 11:22 AM Sebastian Andrzej Siewior wrote: > There is a separation between "setting myself up" and "seeing that a host > wants to talk to me". You are a woman. And if you not done yet done you ignore > the host until you are ready. Can also be ready before the host wants to talk > to you. It depends on your mood / use case (give the use the choice between > storage & network and offer always both because we are self powered). > You never know when she is ready... ;) Please note, that in the example implementation it is userspace who needs to explicitly store "1" into the "connect" attribute; if it is not set, connecting the cable will have no effect and, conversely, if the cable is connected but the "1" is not stored, the gadget will not be seen by the host. Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/17/2012 03:46 AM, Joel Becker wrote:
The configuration has to remain unchanged until the "connect" attribute
is changed (i.e. unconnected). That means the gadget can only be
reconfigured once it is not active.
Yes, that's my understanding of the driver code. What I'm
trying to understand is the trigger for setting connect=1. See, all of
the other configfs steps you outlined make sense to me as "part of the
gadget's internal state". While I don't know what C1 and F1 are (I
assume G1 is Gadget1), I don't know that it matters.
That is part of the abstracted configuration from the UDC [0] side:
- You have at least one "gadget" denoted as G1 here. You could have
more of them. The second would be named G2 in this example. Each
gadget requires one UDC.
- each gadget has at least one configuration descriptor denoted as C1
here. It contains information like VID/PID numbers. You could have
two configurations, where the first one is used if you have a lot of
current available (on host's USB port) and the second where you can
only use the minimum current which is "required" by the USB spec.
- each configuration has at least one function or interface. Denoted as
F1 here. A function is for instance a "mass storage" or a "network"
gadget.
So you _could_ have C1 with F1 as storage and F2 as network and C2 with
F1 as network. Within a config (C*) the functions are independent (that
means F1 und C1 can be != to F1 in C2)
The practical use case would to have a gadget with storage and network
available but if there is not much current available (and you can't
power the disk), the host would select C2 and have only the network
function.
What changes the state to "active"? That is, what triggers
setting connect=1?
First, the user on the UDC side (the script on UDC side) has to
configure the gadget i.e. assign the LUN property to the mass storage
gadget or the MAC address for the network gadget.
Once all configuration is complete, the gadget can be considered as
"ready". configfs will be notified once gadget is considered as ready.
From this point on, the user (of the host) can take a USB cable, plug
into his host and the UDC (gadget) will be enumerated.
Plugging the cable prior the "ready" point would result either in
"nothing" (the host wouldn't notice that a cable has been plugged) or
with a message "the device can't be enumerated".
So back to your question: "connect=1" is triggered by the person that
has the physical power over the cable. But you should have the gadget
configured prior this point _or_ ignore the host and configure the
gadget later.
To give you another example: Your cellphone does not have a gadget in
"ready" state and you plug the cable ("connect=1") into it. The
cellphone notices the plug and gives you the following and the screen:
"Hello good sir. Please choose: a) mass storage or b) MTP something".
Once you pick a or b on your cellphone, the script would activate one
of the two gadgets (sym link it to the UDC in configfs probably) and
it would be seen by the host.
Is it just part of the flow of power-up, or is there
some separation between "setting myself up" and "seeing that a host
wants to talk to me"?
There is a separation between "setting myself up" and "seeing that a
host wants to talk to me". You are a woman. And if you not done yet
done you ignore the host until you are ready. Can also be ready before
the host wants to talk to you. It depends on your mood / use case (give
the use the choice between storage & network and offer always both
because we are self powered).
However it is important that once the configuration on UDC side is done
(or ready) it remains unchanged until you remove it from UDC ("de-ready
it to configfs) and change all attributes.
You shouldn't change the LUN attribute of the mass storage device while
it is active as it has no way to tell the host so.
[0] USB Device Controller. This part where the USB gadget is running.
Joel
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/17/2012 03:46 AM, Joel Becker wrote: The configuration has to remain unchanged until the connect attribute is changed (i.e. unconnected). That means the gadget can only be reconfigured once it is not active. Yes, that's my understanding of the driver code. What I'm trying to understand is the trigger for setting connect=1. See, all of the other configfs steps you outlined make sense to me as part of the gadget's internal state. While I don't know what C1 and F1 are (I assume G1 is Gadget1), I don't know that it matters. That is part of the abstracted configuration from the UDC [0] side: - You have at least one gadget denoted as G1 here. You could have more of them. The second would be named G2 in this example. Each gadget requires one UDC. - each gadget has at least one configuration descriptor denoted as C1 here. It contains information like VID/PID numbers. You could have two configurations, where the first one is used if you have a lot of current available (on host's USB port) and the second where you can only use the minimum current which is required by the USB spec. - each configuration has at least one function or interface. Denoted as F1 here. A function is for instance a mass storage or a network gadget. So you _could_ have C1 with F1 as storage and F2 as network and C2 with F1 as network. Within a config (C*) the functions are independent (that means F1 und C1 can be != to F1 in C2) The practical use case would to have a gadget with storage and network available but if there is not much current available (and you can't power the disk), the host would select C2 and have only the network function. What changes the state to active? That is, what triggers setting connect=1? First, the user on the UDC side (the script on UDC side) has to configure the gadget i.e. assign the LUN property to the mass storage gadget or the MAC address for the network gadget. Once all configuration is complete, the gadget can be considered as ready. configfs will be notified once gadget is considered as ready. From this point on, the user (of the host) can take a USB cable, plug into his host and the UDC (gadget) will be enumerated. Plugging the cable prior the ready point would result either in nothing (the host wouldn't notice that a cable has been plugged) or with a message the device can't be enumerated. So back to your question: connect=1 is triggered by the person that has the physical power over the cable. But you should have the gadget configured prior this point _or_ ignore the host and configure the gadget later. To give you another example: Your cellphone does not have a gadget in ready state and you plug the cable (connect=1) into it. The cellphone notices the plug and gives you the following and the screen: Hello good sir. Please choose: a) mass storage or b) MTP something. Once you pick a or b on your cellphone, the script would activate one of the two gadgets (sym link it to the UDC in configfs probably) and it would be seen by the host. Is it just part of the flow of power-up, or is there some separation between setting myself up and seeing that a host wants to talk to me? There is a separation between setting myself up and seeing that a host wants to talk to me. You are a woman. And if you not done yet done you ignore the host until you are ready. Can also be ready before the host wants to talk to you. It depends on your mood / use case (give the use the choice between storage network and offer always both because we are self powered). However it is important that once the configuration on UDC side is done (or ready) it remains unchanged until you remove it from UDC (de-ready it to configfs) and change all attributes. You shouldn't change the LUN attribute of the mass storage device while it is active as it has no way to tell the host so. [0] USB Device Controller. This part where the USB gadget is running. Joel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Sebastian, Hello Joel, On Friday, August 17, 2012 11:22 AM Sebastian Andrzej Siewior wrote: snip There is a separation between setting myself up and seeing that a host wants to talk to me. You are a woman. And if you not done yet done you ignore the host until you are ready. Can also be ready before the host wants to talk to you. It depends on your mood / use case (give the use the choice between storage network and offer always both because we are self powered). You never know when she is ready... ;) Please note, that in the example implementation it is userspace who needs to explicitly store 1 into the connect attribute; if it is not set, connecting the cable will have no effect and, conversely, if the cable is connected but the 1 is not stored, the gadget will not be seen by the host. Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/17/2012 12:30 PM, Andrzej Pietrasiewicz wrote: There is a separation between setting myself up and seeing that a host wants to talk to me. You are a woman. And if you not done yet done you ignore the host until you are ready. Can also be ready before the host wants to talk to you. It depends on your mood / use case (give the use the choice between storage network and offer always both because we are self powered). You never know when she is ready... ;) Please note, that in the example implementation it is userspace who needs to explicitly store 1 into the connect attribute; if it is not set, connecting the cable will have no effect and, conversely, if the cable is connected but the 1 is not stored, the gadget will not be seen by the host. maybe we should rename connect here to ready or available. It seems to cause confusion. Andrzej Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Thu, Aug 16, 2012 at 03:47:15PM +0200, Sebastian Andrzej Siewior wrote: > On 08/16/2012 03:17 PM, Andrzej Pietrasiewicz wrote: > >A lun is "opened" on storing the "file" attribute of the lun, it is in > >fsg_lun_store_file, storage_common.c. So, again, this is a configfs > >callback. > > > >On storing the connect attribute, the following happens: a composite driver > >is probed, then all the configurations are iterated over, their functions > >being bound in turn. After the gadget is set up this way, the host notices > >connecting a new mass storage device. > > The configuration has to remain unchanged until the "connect" attribute > is changed (i.e. unconnected). That means the gadget can only be > reconfigured once it is not active. Yes, that's my understanding of the driver code. What I'm trying to understand is the trigger for setting connect=1. See, all of the other configfs steps you outlined make sense to me as "part of the gadget's internal state". While I don't know what C1 and F1 are (I assume G1 is Gadget1), I don't know that it matters. What changes the state to "active"? That is, what triggers setting connect=1? Is it just part of the flow of power-up, or is there some separation between "setting myself up" and "seeing that a host wants to talk to me"? Joel -- "The trouble with being punctual is that nobody's there to appreciate it." - Franklin P. Jones http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/16/2012 03:17 PM, Andrzej Pietrasiewicz wrote: A lun is "opened" on storing the "file" attribute of the lun, it is in fsg_lun_store_file, storage_common.c. So, again, this is a configfs callback. On storing the connect attribute, the following happens: a composite driver is probed, then all the configurations are iterated over, their functions being bound in turn. After the gadget is set up this way, the host notices connecting a new mass storage device. The configuration has to remain unchanged until the "connect" attribute is changed (i.e. unconnected). That means the gadget can only be reconfigured once it is not active. So it seems the only chance to call config_item_depend is in a configfs callback. Or is it? Thanks, Andrzej Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, Thank you for your reply. Please find comments inline. On Wednesday, August 15, 2012 10:14 AM Joel Becker wrote: > > So, the config item corresponding to the lun becomes depended on during > > the write file operation, the same with undepend. Can this be expressed > > with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c > > contains a warning not to call the configfs_depend_item() > > from a configfs callback. > > In this case, is store_attribute a configfs callback? > > Yes, attribute store is a callback. So what should you do? > This is where my understanding of your setup logic fails me. At first I > thought fsg_bind_function() was the right place, because it is where you > expect the LUNs to already be configured. But it is, in turn, called > underneath another configfs callback (ufg_gadget_grp_store_connect()). > Can you help me understand the userspace steps that are used to > set up a gadget? The way I read the code, there is some software in the > gadget that sets up the LUN mappings; that is, the host has no idea > "lun01" is backed by a file named "foo". So, if you had a gadget that > just exposed a single LUN, it would have some userspace software at > startup that sets fua=1, removable=0, ro=0, file="foo". At some future > point, the host connects to the gadget. At this point, lun01 is > connected to the host, and it had better not disappear. What part of > the code reacts to the host connect? This is the "open" of the LUN > where I think you should be locking out. >From userspace the procedure to set up a gadget looks like this: (please note that for testing I use _very_ short names like G1, C1, F1; these are not mandatory and, as already pointed out by some, more descriptive names should be used) $ insmod g_usb_functions.ko $ mount -t configfs none /cfg $ mkdir -p /cfg/usb-function-gadget/G1/C1/F1 $ echo -n > /cfg/usb-function-gadget/G1/idVendor $ echo -n > /cfg/usb-function-gadget/G1/idProduct $ echo -n 0xff > /cfg/usb-function-gadget/G1/bcdDevice $ echo Manufacturer > /cfg/usb-function-gadget/G1/iManufacturer $ echo 123abc > /cfg/usb-function-gadget/G1/iSerialNumber $ echo Gadget > /cfg/usb-function-gadget/G1/iProduct $ echo -n f_mass_storage > /cfg/usb-function-gadget/G1/C1/F1/name $ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage $ echo -n 1 > /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/luns $ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 $ echo -n /root/file.img > /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0/file $ echo -n 1 > /cfg/usb-function-gadget/G1/connect The mapping between luns and their backing files is maintained in alloc_fsg_lun, f_mass_storage.c; the function needs improvement. The intended logic is not to allow more than 1 lun of the same name at the same time. A lun is "opened" on storing the "file" attribute of the lun, it is in fsg_lun_store_file, storage_common.c. So, again, this is a configfs callback. On storing the connect attribute, the following happens: a composite driver is probed, then all the configurations are iterated over, their functions being bound in turn. After the gadget is set up this way, the host notices connecting a new mass storage device. So it seems the only chance to call config_item_depend is in a configfs callback. Or is it? Thanks, Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Hello Joel, Thank you for your reply. Please find comments inline. On Wednesday, August 15, 2012 10:14 AM Joel Becker wrote: snip So, the config item corresponding to the lun becomes depended on during the write file operation, the same with undepend. Can this be expressed with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c contains a warning not to call the configfs_depend_item() from a configfs callback. In this case, is store_attribute a configfs callback? snip Yes, attribute store is a callback. So what should you do? This is where my understanding of your setup logic fails me. At first I thought fsg_bind_function() was the right place, because it is where you expect the LUNs to already be configured. But it is, in turn, called underneath another configfs callback (ufg_gadget_grp_store_connect()). Can you help me understand the userspace steps that are used to set up a gadget? The way I read the code, there is some software in the gadget that sets up the LUN mappings; that is, the host has no idea lun01 is backed by a file named foo. So, if you had a gadget that just exposed a single LUN, it would have some userspace software at startup that sets fua=1, removable=0, ro=0, file=foo. At some future point, the host connects to the gadget. At this point, lun01 is connected to the host, and it had better not disappear. What part of the code reacts to the host connect? This is the open of the LUN where I think you should be locking out. From userspace the procedure to set up a gadget looks like this: (please note that for testing I use _very_ short names like G1, C1, F1; these are not mandatory and, as already pointed out by some, more descriptive names should be used) $ insmod g_usb_functions.ko $ mount -t configfs none /cfg $ mkdir -p /cfg/usb-function-gadget/G1/C1/F1 $ echo -n some id /cfg/usb-function-gadget/G1/idVendor $ echo -n some id /cfg/usb-function-gadget/G1/idProduct $ echo -n 0xff /cfg/usb-function-gadget/G1/bcdDevice $ echo Manufacturer /cfg/usb-function-gadget/G1/iManufacturer $ echo 123abc /cfg/usb-function-gadget/G1/iSerialNumber $ echo Gadget /cfg/usb-function-gadget/G1/iProduct $ echo -n f_mass_storage /cfg/usb-function-gadget/G1/C1/F1/name $ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage $ echo -n 1 /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/luns $ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 $ echo -n /root/file.img /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0/file $ echo -n 1 /cfg/usb-function-gadget/G1/connect The mapping between luns and their backing files is maintained in alloc_fsg_lun, f_mass_storage.c; the function needs improvement. The intended logic is not to allow more than 1 lun of the same name at the same time. A lun is opened on storing the file attribute of the lun, it is in fsg_lun_store_file, storage_common.c. So, again, this is a configfs callback. On storing the connect attribute, the following happens: a composite driver is probed, then all the configurations are iterated over, their functions being bound in turn. After the gadget is set up this way, the host notices connecting a new mass storage device. So it seems the only chance to call config_item_depend is in a configfs callback. Or is it? Thanks, Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On 08/16/2012 03:17 PM, Andrzej Pietrasiewicz wrote: A lun is opened on storing the file attribute of the lun, it is in fsg_lun_store_file, storage_common.c. So, again, this is a configfs callback. On storing the connect attribute, the following happens: a composite driver is probed, then all the configurations are iterated over, their functions being bound in turn. After the gadget is set up this way, the host notices connecting a new mass storage device. The configuration has to remain unchanged until the connect attribute is changed (i.e. unconnected). That means the gadget can only be reconfigured once it is not active. So it seems the only chance to call config_item_depend is in a configfs callback. Or is it? Thanks, Andrzej Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Thu, Aug 16, 2012 at 03:47:15PM +0200, Sebastian Andrzej Siewior wrote: On 08/16/2012 03:17 PM, Andrzej Pietrasiewicz wrote: A lun is opened on storing the file attribute of the lun, it is in fsg_lun_store_file, storage_common.c. So, again, this is a configfs callback. On storing the connect attribute, the following happens: a composite driver is probed, then all the configurations are iterated over, their functions being bound in turn. After the gadget is set up this way, the host notices connecting a new mass storage device. The configuration has to remain unchanged until the connect attribute is changed (i.e. unconnected). That means the gadget can only be reconfigured once it is not active. Yes, that's my understanding of the driver code. What I'm trying to understand is the trigger for setting connect=1. See, all of the other configfs steps you outlined make sense to me as part of the gadget's internal state. While I don't know what C1 and F1 are (I assume G1 is Gadget1), I don't know that it matters. What changes the state to active? That is, what triggers setting connect=1? Is it just part of the flow of power-up, or is there some separation between setting myself up and seeing that a host wants to talk to me? Joel -- The trouble with being punctual is that nobody's there to appreciate it. - Franklin P. Jones http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Tue, Jul 10, 2012 at 10:54:44AM +0200, Andrzej Pietrasiewicz wrote: > Dear Joel, > > Thank you for your review. > > @Sebastian, Alan, Felipe: Thank you, too. > > On Monday, July 02, 2012 11:09 AM Joel Becker wrote: > > > > > > > > As a prerequisite it adds an operation to configfs. The operation allows > > > checking if it is ok to remove a pseudo directory corresponding to a > > > configfs item/group. > > > > I NAK'd that patch because you should be using > > configfs_depend_item(). If you have trouble with that, let's talk. > > > > Now I see the configfs_depend_item() is the way to go. I am in doubt, > though, so could you please throw some light on it? Here is why: > As an example I did a quick-and-dirty port of f_mass_storage to the new, > configfs-based approach. The business logic of this function is that > once a lun is opened, it must not be changed (deleted, in particular) > until it is closed. The moment the lun is opened is defined by a write > to a configfs "file" attribute of a lun config item: > >+-/lunX >| | >| +-file >| | >| +-nofua >| | >| +-removable >| | >| +-ro > > So, the config item corresponding to the lun becomes depended on during > the write file operation, the same with undepend. Can this be expressed > with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c > contains a warning not to call the configfs_depend_item() > from a configfs callback. > In this case, is store_attribute a configfs callback? Hey Andrzej, I'm sorry it took me so long to write back. I wanted a chance to read and understand your code, so I could make some intelligent comments. But first, a small aside. Rather than filp_open() a filename within the kernel, with all of its attendant state problems, you should just take a file descriptor. You can then let userspace permissions and other things Just Work. See fs/ocfs2/heartbeat.c:o2hb_region_dev_write() for an example of o2hb doing exactly this. It takes a file descriptor and fgets() the filp. The process writing the fd can actually close the file right after; the heartbeat code has its reference. Let's continue with that example. Just like your code, when o2hb is given its fd, it starts up the heartbeat infrastructure. So not only does it hold a reference on the filp, it is starting threads and such. However, it also does not block deletion of the object. If you rmdir() the config_item, it will shut down the threads and drop the filp. This is analogous to your problem. What happens if you remove a heartbeat device underneath a running ocfs2 filesystem? Why, it must crash! We don't want that, so when the ocfs2 filesystem is mounted, it uses configfs_depend_item() to pin that heartbeat device. This is what I mean by pinning outside the configfs callback. Yes, attribute store is a callback. So what should you do? This is where my understanding of your setup logic fails me. At first I thought fsg_bind_function() was the right place, because it is where you expect the LUNs to already be configured. But it is, in turn, called underneath another configfs callback (ufg_gadget_grp_store_connect()). Can you help me understand the userspace steps that are used to set up a gadget? The way I read the code, there is some software in the gadget that sets up the LUN mappings; that is, the host has no idea "lun01" is backed by a file named "foo". So, if you had a gadget that just exposed a single LUN, it would have some userspace software at startup that sets fua=1, removable=0, ro=0, file="foo". At some future point, the host connects to the gadget. At this point, lun01 is connected to the host, and it had better not disappear. What part of the code reacts to the host connect? This is the "open" of the LUN where I think you should be locking out. Joel -- "Only a life lived for others is a life worth while." -Albert Einstein http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] USB gadget - configfs
On Tue, Jul 10, 2012 at 10:54:44AM +0200, Andrzej Pietrasiewicz wrote: Dear Joel, Thank you for your review. @Sebastian, Alan, Felipe: Thank you, too. On Monday, July 02, 2012 11:09 AM Joel Becker wrote: snip As a prerequisite it adds an operation to configfs. The operation allows checking if it is ok to remove a pseudo directory corresponding to a configfs item/group. I NAK'd that patch because you should be using configfs_depend_item(). If you have trouble with that, let's talk. Now I see the configfs_depend_item() is the way to go. I am in doubt, though, so could you please throw some light on it? Here is why: As an example I did a quick-and-dirty port of f_mass_storage to the new, configfs-based approach. The business logic of this function is that once a lun is opened, it must not be changed (deleted, in particular) until it is closed. The moment the lun is opened is defined by a write to a configfs file attribute of a lun config item: +-/lunX | | | +-file | | | +-nofua | | | +-removable | | | +-ro So, the config item corresponding to the lun becomes depended on during the write file operation, the same with undepend. Can this be expressed with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c contains a warning not to call the configfs_depend_item() from a configfs callback. In this case, is store_attribute a configfs callback? Hey Andrzej, I'm sorry it took me so long to write back. I wanted a chance to read and understand your code, so I could make some intelligent comments. But first, a small aside. Rather than filp_open() a filename within the kernel, with all of its attendant state problems, you should just take a file descriptor. You can then let userspace permissions and other things Just Work. See fs/ocfs2/heartbeat.c:o2hb_region_dev_write() for an example of o2hb doing exactly this. It takes a file descriptor and fgets() the filp. The process writing the fd can actually close the file right after; the heartbeat code has its reference. Let's continue with that example. Just like your code, when o2hb is given its fd, it starts up the heartbeat infrastructure. So not only does it hold a reference on the filp, it is starting threads and such. However, it also does not block deletion of the object. If you rmdir() the config_item, it will shut down the threads and drop the filp. This is analogous to your problem. What happens if you remove a heartbeat device underneath a running ocfs2 filesystem? Why, it must crash! We don't want that, so when the ocfs2 filesystem is mounted, it uses configfs_depend_item() to pin that heartbeat device. This is what I mean by pinning outside the configfs callback. Yes, attribute store is a callback. So what should you do? This is where my understanding of your setup logic fails me. At first I thought fsg_bind_function() was the right place, because it is where you expect the LUNs to already be configured. But it is, in turn, called underneath another configfs callback (ufg_gadget_grp_store_connect()). Can you help me understand the userspace steps that are used to set up a gadget? The way I read the code, there is some software in the gadget that sets up the LUN mappings; that is, the host has no idea lun01 is backed by a file named foo. So, if you had a gadget that just exposed a single LUN, it would have some userspace software at startup that sets fua=1, removable=0, ro=0, file=foo. At some future point, the host connects to the gadget. At this point, lun01 is connected to the host, and it had better not disappear. What part of the code reacts to the host connect? This is the open of the LUN where I think you should be locking out. Joel -- Only a life lived for others is a life worth while. -Albert Einstein http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Dear Joel, Thank you for your review. @Sebastian, Alan, Felipe: Thank you, too. On Monday, July 02, 2012 11:09 AM Joel Becker wrote: > > > As a prerequisite it adds an operation to configfs. The operation allows > > checking if it is ok to remove a pseudo directory corresponding to a > > configfs item/group. > > I NAK'd that patch because you should be using > configfs_depend_item(). If you have trouble with that, let's talk. > Now I see the configfs_depend_item() is the way to go. I am in doubt, though, so could you please throw some light on it? Here is why: As an example I did a quick-and-dirty port of f_mass_storage to the new, configfs-based approach. The business logic of this function is that once a lun is opened, it must not be changed (deleted, in particular) until it is closed. The moment the lun is opened is defined by a write to a configfs "file" attribute of a lun config item: +-/lunX | | | +-file | | | +-nofua | | | +-removable | | | +-ro So, the config item corresponding to the lun becomes depended on during the write file operation, the same with undepend. Can this be expressed with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c contains a warning not to call the configfs_depend_item() from a configfs callback. In this case, is store_attribute a configfs callback? Thanks, Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 0/2] USB gadget - configfs
Dear Joel, Thank you for your review. @Sebastian, Alan, Felipe: Thank you, too. On Monday, July 02, 2012 11:09 AM Joel Becker wrote: snip As a prerequisite it adds an operation to configfs. The operation allows checking if it is ok to remove a pseudo directory corresponding to a configfs item/group. I NAK'd that patch because you should be using configfs_depend_item(). If you have trouble with that, let's talk. Now I see the configfs_depend_item() is the way to go. I am in doubt, though, so could you please throw some light on it? Here is why: As an example I did a quick-and-dirty port of f_mass_storage to the new, configfs-based approach. The business logic of this function is that once a lun is opened, it must not be changed (deleted, in particular) until it is closed. The moment the lun is opened is defined by a write to a configfs file attribute of a lun config item: +-/lunX | | | +-file | | | +-nofua | | | +-removable | | | +-ro So, the config item corresponding to the lun becomes depended on during the write file operation, the same with undepend. Can this be expressed with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c contains a warning not to call the configfs_depend_item() from a configfs callback. In this case, is store_attribute a configfs callback? Thanks, Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
