Re: ConfigFS + Target Mode Engine API discussion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-09-10 at 23:38 -0700, Joel Becker wrote:
> On Wed, Sep 10, 2008 at 09:29:18PM -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2008-09-10 at 19:13 -0700, Joel Becker wrote:
> > > On Wed, Sep 10, 2008 at 06:42:46PM -0700, Nicholas A. Bellinger wrote:
> > > > So I am thinking about the following question:  What would be the
> > > > preferred method for calling ct_group_ops->make_group() in order to
> > > > create the $CONFIGFS/target/$FABRIC struct config_item directly from
> > > > target_fabric_configfs_register() call?  From there, the config group
> > > > hanging off $CONFIGFS/target/$FABRIC will be fabric dependent and
> > > > providing their own groups, items, depends, from the passed *fabric_cit.
> > > > How do I "simulate" a mkdir(2) configfs -> make_group() call coming from
> > > > the fabric module itself..?   This would be assuming that both mkdir(2)
> > > 
> > > 	That's precisely what you don't do with configfs.  It's a
> > > defined "not to be done" thing.  So there's no preferred way, there's no
> > > way at all.
> > > 	What you want do to is drive this from mkdir().  The
> > > make_group() will look up the sub-module it needs and return the
> > > appropriate item.
> > > 
> > 
> > Whew, good thing I asked about this case first..  :-)
> 
> 	Can you give me a more complete description of what you're
> trying to do?  that way I can maybe help with some suggestions.
> 

Sure, the process to get the things up and running would look like:

# Load in the generic target's configfs infrastructure
modprobe target_core_configfs

*) $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).

config_item_get() is also called in target_fabric_configfs_register()
and returns the newly allocated struct config_item to
iscsi_target_mod.ko code to then create new struct config_groups for
iSCSI target fabric specific abstractions and LUN mappings between
$CONFIGFS/target/core/$STORAGE_OBJECT and Fabric dependent code. I think
the latter would be done with symlinks between $FABRIC <-> Generic
Target Core Storage Object.

Anyways, knowing that make_group() and drop_item() will *NEVER* be
called internally clears up alot for me.  I will keep working on this
setup and let you know if I run into any more head scratchers.

Thanks again Joel!

--nab


--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux