On Tuesday, November 27, 2012 5:00 PM Sebastian Andrzej Siewior wrote: > On 11/27/2012 09:57 AM, Andrzej Pietrasiewicz wrote: > >> |mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1 > >> |mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0 > >> |mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_1 > >> > >> So you setup two luns without this patch. Would that work for you? > >> > > I think we _still_ need a way to programmatically create/remove > > configfs directories. Without it, this: "After name is written it will > > request the module and special configuration related files pop up." > > (http://www.spinics.net/lists/linux-usb/msg75118.html) > > > > is only possible for a static, predefined number of configuration > > subdirectories. Can you guarantee there will be only such a need? > > No I can't but until now I don't such a need. > > > Are you sure lun# directories will not be created programmatically? > > https://lkml.org/lkml/2012/11/26/584 > > they are not by target and they are not complaining. We need it if we use > the num_luns file which I don't think is useful. > > > And there are problems to be addressed right now, not possibly in the > > future: take the intrefaceXX (read-only) directory, which contains > > information about altsetting, interface class, interface number, > > endpoints etc. It can be created only after the gadget has actually > > been bound. But before the gadget is bound it is being configured and > > the configfs directories must already be there, so any default_groups > > are already created. > > Here I understand it. This is to some point a limitation of the gadget > framework. We do know the number of interface that will be available > before we bind. We simply don't know the endpoint number. There are two > exceptions to what I just wrote: > - g_zero drops the ISO endpoints if the UDC has no UDC support for it. > This should not happen on-the-fly. > - UAC2 may want to make the number interfaces (and therefore configure > able) and function (play / record) configurable. >
So do we know everything before bind or we don't? > > So the interfaceXX directory cannot be implemented as a default group, > > but must be created programmatically. > > > > Also, there is an idea to unbind the gadget with just doing rmdir > > /cfg/...../gadgetX: > > http://www.spinics.net/lists/linux-usb/msg74893.html > > Since we link the gadget to the function, we should unlink it. > > > This implies doing a recursive rmdir first on its subdirectories - a > > programmatic rmdir. > > Hmm. On target I have to rmdir manually > > |unlink naa.6001405c3214b06a/tpgt_1/lun/lun_2/virtual_scsi_port > |unlink naa.6001405c3214b06a/tpgt_1/lun/lun_3/virtual_scsi_port > |rmdir naa.6001405c3214b06a/tpgt_1/lun/lun_2 > |rmdir naa.6001405c3214b06a/tpgt_1/lun/lun_3 > |rmdir naa.6001405c3214b06a/tpgt_1/ > |rmdir naa.6001405c3214b06a/ > |cd .. > |rmdir usb_gadget > > to make it all go away. Couldn't we have a tool to manage all this? > target has such a thing, you have just select a few things via a CLI tool > and the tool creates the directories for you _and_ removes them later on. > I don't want to push python on anyone but the removal magic is simply > straight forward: unlink the disk ports, rmdir luns, tpgt,. > > > Taken all this into account, I would like to have a way to > > programmatically create and remove configfs directories. > > Right now creating them is like scratching the left ear with the hand > > under the right knee. And it leads to comments like: "Looking at this: > > full_name_hash(), d_alloc(), d_add(), d_drop(), dput(). Do you write a > > filesystem?" > > http://www.spinics.net/lists/linux-usb/msg74841.html > > That was wrong. Pushing it into configs is better but I am not sure we > need it. I understand the need for things that pop later like interfaceXX > but couldn't the user manually create them if he needs them? > What name shall the user use? How to know which user-created directory should correspond to which actual interface? If there are, say, 3 interfaces, what would: $ mkdir interface873246 mean? And in general, what would $ mkdir rykcq1234 mean? Let's go one directory deeper in the hierarchy and suppose there is no programmatic directories creation. So we $ cd interface<something> so that we can create the endpoint directories. And now what? What names shall the user use for the endpoint directories? Oh, that's simple: just see what the endpoint directories' names are. But wait, aren't we just creating them? Please also see Michał's point about user interface. 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/
