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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
