Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

[Greg KH <greg@kroah.com>]

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