FUJITA Tomonori, on 10/06/2010 11:25 AM wrote: >>> The main issue here is that the user still needs to know the $LPORT_WWPN >>> before hand (either from looking at a sticker on the card, or via >>> another method) in order to preform the initial TFO->fabric_make_wwn() >>> -> $TCM_MOD_make_wwn() operation. So what we need is a configfs attrib >>> at the top level TCM fabric group in order to see a list of the >>> available hardware ports from the specific $TCM_MOD. What I was >>> thinking for TCM HW fabric module ports would be to have something like: >>> >>> /sys/kernel/config/target/$TCM_MOD/hw_ports >>> >>> that would walk the struct pci_dev looking for fabric module specific HW >>> target mode capabilities. I assume this is what you had in mind for >>> drivers/scsi/ibmvscsi as well, yes..? >> >> Doesn't sound so. >> >> I want the driver to create necessary target directories in >> /sys/kernel/config/target/ibmvscsit/ automatically. > > In addition, I also think that /sys/kernel/config/target/$TCM_MOD > should show up automatically when I load the module. > > vine:/home/fujita# modprobe iscsi_target_mod > > Then why do I need to create iscsi directory by hand? Hello Tomonori, Welcome to the world of configfs-based SCSI target configuration infrastructure! Configfs is user space driven and only by user space. This is the main reason why I from the very beginning have writing that it isn't suitable for managing SCSI targets. Needless to say that SCST's sysfs-based configuration infrastructure doesn't suffer from this limitation and allows creation of entries from both kernel and user spaces. Vlad -- 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
