On Fri, 2008-10-17 at 10:39 -0700, Greg KH wrote: > 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? > What are the preferred methods for accessing struct block_device and struct scsi_device from "name"..? > > 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. > <nod> As I am coding configfs_follow_symlink() to work with sysfs source symlinks I am starting to see that.. :-) I am still going to hack on it for a bit and see if I can get it running so that it works.. > > 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. > Well, the goal is to use as much existing infrastructure as possible for the generic target_core_mod when referencing Linux $STORAGE_OBJECTs, be they struct scsi_device, struct block_device or struct file.. :-) Having *SOME* type of communication between sysfs and configfs so that those kernel data structures mentioned above can be accessed through configfs still does seem like it could be useful.. Thanks for your comments, --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
