On Fri, 2008-09-12 at 13:15 -0700, Joel Becker wrote: > On Thu, Sep 11, 2008 at 01:58:49AM -0700, Nicholas A. Bellinger wrote: > > *) $CONFIGFS/target is created with configfs_register_subsystem() > > > > *) $CONFIGFS/target/core is created as a default group under struct > > configfs_subsystem->su_group to interact with generic target mode > > engine's storage objects (eg: SCSI HCTL referenced devices, LVM UUID, MD > > UUID). > > > > ........... > > > > # Load LIO-Target using function symbols from target_core_configfs > > modprobe iscsi_target_mod > > > > module_init() from iscsi_target_mod (eg: the fabric module) calls > > target_fabric_configfs_register() in target_core_configfs.ko, which is a > > small wrapper for calling sys_mkdir($CONFIGFS/target/$FABRIC) to kick > > off the struct config_group_operations->make_group() to create a struct > > config_item for /sys/kernel/config/target/iscsi (or whatever the fabric > > is called). > > No, you don't do this. Like I said, configfs clients let > userspace create and destroy items. Not kernelspace. Do not call > sys_mkdir()/sys_rmdir() from your modules. > If you don't do this, you also don't need your lookup_hash() > export. Your code should be behaving as if it didn't know the > filesystem view existed. > I'm trying to understand what you're actually doing. Not the > "I want iscsi_target_mod to appear under target/iscsi" part, but why it > needs to be there in the first place. how it all connects together. > Well, the startup 'fabric registration' is only case where I figured vfs_mkdir($CONFIGFS/target/$FABRIC) being called in order to have the fabric struct config_item appear at modprobe $FABRIC_MOD *BEFORE* the user did anything would be beneficial at all. If vfs_mkdir() was not called from transport_fabric_register_configfs(), it only means user would have call mkdir $CONFIGFS/target/$FABRIC and/or mkdir -p $CONFIGFS/target/$FABRIC/endpoint to kick off one common make_group() for $FABRIC (that lives in target_core_configfs.c) and then make_group() that likes inside of $FABRIC_MOD who's parent is $CONFIGFS/target. In LIO-Target's case, this would be creating a new iSCSI Qualified Name with mkdir $CONFIGFS/target/iscsi/iqn.superturobdiskarry The only real reason I am stuck on this is so that the modprobe $FABRIC does not need to be followed by a user *REQUIRED* mkdir -p $CONFIGFS/target/$FABRIC, before a normal operation like: mkdir $CONFIGFS/target/$FABRIC/endpoint to kick off the expected two make_groups() and the attributes in $CONFIGFS/target/$FABRIC to be possibily tuned *BEFORE* the $FABRIC/$endpoint before the userspace mkdir -p. Which is not a big deal I suppose, as everything will be there after mkdir -p $CONFIGFS/target/iscsi/iqn.superturobdiskarry anyways, but I thought it could be useful. Anyways, once the $FABRIC's struct config_item appears, everything from that point is done in userspace as you (as the configfs author) would expect with configfs structs located in $FABRIC_MOD driven by userspace ops. It is this method of automatic ops at modprobe $FABRIC_MOD for struct config_item's particular struct target_fabric_configfs hanging of the generic target's struct configfs_subsystem where any possible benefit for automation of setup for a configfs enabled Generic Target Engine many lie. Same with the shutdown case for $FABRIC_MOD and calling transport_fabric_deregister_configfs() at rmmod $FABRIC_MID. If vfs_rmdir() was NOT called, the user would be expected to call rmdir $CONFIGFS/target/$FABRIC before rmmod $FABRIC_MOD. It could be thought of as: A special case where vfs_mkdir() or vfs_rmdir() being called in order to create the "multi-module" configfs subsystem containing struct config_item_types() and struct config_*_operations in different kernel modules.. As I don't believe the examples in Documentation/filesystems/configfs or working code in fs/ocfs2/cluster/nodemanager.c have this requirement AFAICT, it could be considered a new use for configfs... :-) I will be working on filling in target-ctl IOCTL parts in iscsi_target_configfs.c, which look like expected configfs (not the special case above) until you get to that other special case mentioned earlier: Wanting to creat a LUN mapping from a storage object from a T10 EVPD Unit Serial to a registered $CONFIGFS/target/$FABRIC/endpoint/lun when the $CONFIGFS/target/core/$T10_EVPD_UNIT_SERIAL does not exist.. Thanks Joel! --nab > Joel > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
