Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757355AbYJQSsz (ORCPT ); Fri, 17 Oct 2008 14:48:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754711AbYJQSsp (ORCPT ); Fri, 17 Oct 2008 14:48:45 -0400 Received: from kroah.org ([198.145.64.141]:38521 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754748AbYJQSsn (ORCPT ); Fri, 17 Oct 2008 14:48:43 -0400 Date: Fri, 17 Oct 2008 10:39:59 -0700 From: Greg KH To: "Nicholas A. Bellinger" Cc: Joel Becker , LKML , Linux-fsdevel , linux-scsi , "Linux-iSCSI.org Target Dev" , SCST-Devel , Alan Stern , Andrew Morton , Christoph Hellwig Subject: Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source. Message-ID: <20081017173959.GC2221@kroah.com> References: <1224226555.5556.279.camel@haakon2.linux-iscsi.org> <20081017074453.GA4850@kroah.com> <1224231739.5556.303.camel@haakon2.linux-iscsi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1224231739.5556.303.camel@haakon2.linux-iscsi.org> User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2593 Lines: 63 On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote: > On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote: > > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote: > > > Hi Joel, Greg and Co, > > > > > > Here is the the first working code for allowing configfs to handle > > > symlinks from sysfs struct kobject based code. Here is the commit: > > > passing struct kobject into generic target_core_mod subsystem plugins > > > for locating struct block_device and struct scsi_device.. > > > > Um, no. > > > > You are trying to create symlinks dynamically across superblocks and > > mount points? As one of your #warning states, this isn't possible to do > > correctly, nor is it even a good idea. > > > > So I'd have to reject this patch, sorry. > > > > What is the problem you are attempting to solve here? > > > > So, the generic target_core_mod engine that lives > under /sys/kernel/config/target/core needs a method to locate struct > block_device and struct scsi_device for access via bio_submit() and > scsi_execute_() respectively. Then just pass the "name" of the block device into a configfs file, nothing more is needed, right? > Originally, target_core_mod used key echoed through configfs attributes > like so: > > export TARGET=/sys/kernel/config/target/core/ > > # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod > mkdir -p $TARGET/iblock_0/lvm_test0 > # OLD METHOD to reference struct block_device > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control > echo 1 > $TARGET/iblock_0/lvm_test0/enable > # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device > ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2 No, you can't do a symlink across superblocks and expect it to work like you are thinking internally. > The other point is that since configfs is based on sysfs code, it only > makes sense to provide a API through configfs to take advantage of > kernel data structures that can be referenced using wrappers to > container_of() in include/linux/ in a common way. No, just because configfs looks like sysfs internally, does not mean they are related in any manner. We have been down this argument many times in the past, please don't bring it up again, it has no bearing on this at all. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/