From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756662AbYILQbt (ORCPT ); Fri, 12 Sep 2008 12:31:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752667AbYILQbi (ORCPT ); Fri, 12 Sep 2008 12:31:38 -0400 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]:30551 "HELO smtp116.sbc.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752724AbYILQbh (ORCPT ); Fri, 12 Sep 2008 12:31:37 -0400 X-YMail-OSG: 3XSAGpsVM1mm7hl1CPhvgNPd9yOORu9nN3sqXgHIcqauDCqbFHxC9Ipeyima5GlXSMYYs8Tj1LYcdcS0JCtJbytH0UvoW9cvS.NQHhDi5XHTPJTzXPCH74Uw1FgdztzPOifnXGYIRqQwwCpuqp38fM1P X-Yahoo-Newman-Property: ymail-3 Subject: Re: ConfigFS + Target Mode Engine API discussion From: "Nicholas A. Bellinger" To: linux-iscsi-target-dev@googlegroups.com Cc: Joel Becker , linux-scsi , SCST-Devel , LKML In-Reply-To: <1221123529.27831.343.camel@haakon2.linux-iscsi.org> References: <1221087547.27831.165.camel@haakon2.linux-iscsi.org> <20080910233107.GC23864@mail.oracle.com> <1221097366.27831.216.camel@haakon2.linux-iscsi.org> <20080911021331.GA12902@mail.oracle.com> <1221107358.27831.289.camel@haakon2.linux-iscsi.org> <20080911063846.GB16583@mail.oracle.com> <1221123529.27831.343.camel@haakon2.linux-iscsi.org> Content-Type: text/plain Date: Fri, 12 Sep 2008 09:24:52 -0700 Message-Id: <1221236692.3401.28.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2008-09-11 at 01:58 -0700, Nicholas A. Bellinger wrote: > 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! > Hi Joel, After some more thought and a few hours of effort, I was able to get some code up using the model above between a new target_core_configfs.ko and iscsi_target_mod.ko (LIO-Target): http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=1a48fb089e1ee1cff5ef02b401d365fdf206cf69 The one symbol that I required out of fs/namei.c for vfs_mkdir() that was not available was lookup_hash(), and the symbol is exported in the commit so that drivers/lio-core/transport_core_configfs.c:do_configfs_rmdir() works as expected. There is another version of do_configfs_rmdir() that uses the exported lookup_one_len(), but that one is not working just quite yet. Perhaps there is value in lookup_hash() being defined as EXPORT_SYMBOL_GPL(). Now that the basic configfs structure between a generic engine <-> fabric is in place, the next steps will be to enable the LIO-Target and LIO-Core IOCTLs into make_group() and drop_item() calls. Have a look and let me know what you think.. I will ping you when the first pieces of LIO-Target functionality are up and running.. :-) --nab