On Mon, Feb 7, 2011 at 12:53 PM, Joel Becker <jlbec@xxxxxxxxxxxx> wrote: > > On Mon, Feb 07, 2011 at 12:41:18PM +0100, Bart Van Assche wrote: > > On Fri, Feb 4, 2011 at 7:45 AM, Nicholas A. Bellinger > > <nab@xxxxxxxxxxxxxxx> wrote: > > > Please consider the following patch series for mainline target code. > > > It consists of predominately configfs bugfixes uncovered with recent SLUB > > > poison testing, and proper removal of legacy procfs target_core_mib.c code. > > > Note that the complete set of fabric independent statistics (SCSI MIBs) and > > > fabric dependent statistics will be included as native configfs group context > > > 'per value' attribute series during the .39 time frame. > > > > I'm still not convinced that using configfs in a storage target as the > > only interface between kernel space and user space is a good idea. > > While configfs may satisfy all the needs of an iSCSI target, the use > > of configfs in combination with hot-pluggable HCAs is really awkward. > > Whenever a HCA is plugged in, the user has to issue mkdir commands to > > make these interfaces appear in configfs. And whenever a HCA is > > removed, stale information will remain present in configfs until the > > user issues an rmdir command. As we all know, it is not possible for a > > storage target to make these directories appear / disappear > > automatically in configfs because of basic configfs design choices. > > Any configuration would have to be handled. We have plenty of > stuff that is handled by userspace hooks out of udev, etc. That's a > normal hotplug process. > Essentially, you're not challenging Nick's use of configfs here, > you're challenging his environment of setting up the target stack from > userspace. Hello Joel, While I'm fine with using configfs where appropriate, I do not agree with the choice of configfs as the only interface between user space and kernel for a storage target. It seems overkill to me to depend on user space software to make sure that the user space visible information about HCAs is up to date while the target core could easily ensure itself that such information would be up to date if it would be using sysfs instead of configfs. Furthermore, there is currently no mechanism present in the target code to inform user space about HCA list updates. Even more: no mechanism has been implemented yet to allow user space to find out which HCAs are controlled by a target driver nor which names have been assigned by a target driver to the HCAs it controls. This seems like an oversight to me. Regarding udev: no udev events are generated for HCAs controlled by target drivers since the objects created by target drivers are not regular devices. Bart. -- 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
