On Wed, 2010-10-06 at 16:43 +0900, FUJITA Tomonori wrote: > On Wed, 06 Oct 2010 00:22:10 -0700 > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> 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. > > > > > > > > > > Hmmmm, well configfs is entirely driven by userspace syscalls, so we > > I think that we really want to configure things by kernel space too > because the scsi target stuff need to handle hardware. > > Need to load the module and create the module name directory by name? > > Need to read the content in sysfs to get the hardware info and create > the directories appropriate for the hardware by hand? > > Looks strange and inconvenient interface to me. Why can't the kernel > just create the directory layout that suits to the hardware for users? > > Actually, I already had some code that could simulate mkdir(2) and rmdir(2) to do exactly what you are talking about here for doing configfs groups ops from kernel space in 2008 in to assist with the IOCTL -> configfs v3.0 conversion work. Joel gave this a big NACK back then, and I removed the code from target_core_configfs.c shortly thereafter. But really, pushing this logic into userspace and making python/perl/shell code do these type of things IMHO makes the kernel level target code cleaner. Of course I think having something to create configfs groups from kernelspace is very useful for debugging and ProcFS/SysFS/NetLink/IOCTL -> ConfigFS conversion purposes, but I will have to defer to Joel for his reasons of not allowing configfs consumers to do this. (CC'ing linux-fsdevel) --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
