<Trimming CC list> On Mon, 2010-11-15 at 18:49 +0100, Bart Van Assche wrote: > On Mon, Nov 15, 2010 at 6:19 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > > [ ... ] > > Perhaps consider a new alternative like the device tree as Greg suggested > > or maybe finally accept the harsh realities of ConfigFS. > > I think that Vlad has already explained several times why ConfigFS is > not suited for the needs of a storage target: a storage target must > not only be able to accept configuration information from userspace > but must also be able to create new directories and file nodes itself. > See e.g. this message from October 6: > http://kerneltrap.org/mailarchive/linux-kernel/2010/10/6/4628664. > Sorry, but this post explains nothing but a single misguided and uninformed opinion, with no hard facts on the actual usage of a native configfs control plane within target mode infrastructure. The hard facts are: Using configfs works to drive the generation/release, real time configuration, dependancy relationships because: *) configfs represents the individual target data structures who's creation/deletion are driven from enterily userspace. *) The parent/child relationships of dependant data structures is handled transparently to the configfs consumer (eg: no hard requirement internal reference counting) *) The module reference counting of target core -> fabric module is handled transparently to configfs consumers *and* TCM fabric modules *) The current implementation of TCM/ConfigFS contains no global locks. Each /sys/kernel/config/target/$FABRIC_1 operates independently of /sys/kernel/config/target/$FABRIC_2 *) Expecting target fabric module developers to (by-hand) add struct config_groups, struct kobjects or anything else directly to their fabric module code is really clumsy and stupid. This problem was solved earlier this year in TCM v4.0 with the advent of: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/target/target_core_fabric_configfs.c;hb=refs/heads/lio-4.0 What this code means is that target fabric module developers no longer has to duplicate complex control path code, and all of the interesting port attributes (like ALUA secondary access state for example) are transparent to new fabric modules, and 'just work'. We can even generate *functional* configfs skeletons for new fabric modules using tcm_mod_builder.py discussed here: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=Documentation/target/tcm_mod_builder.txt;hb=refs/heads/lio-4.0 For the specific case of the target control path, until someone from SCST can present some hard facts *and* running code about the target mode configfs vs. sysfs debate, the discussion is like comparing oil and water. Again, please do not take this as the LIO maintainer saying 'you should stop working on SCST code XYZ', because that is *not* what I am saying. We are simply stating that we already have a fully functional configfs backend and generic target fabric independent infrastrucutre that has not only been reviewed no less than five times this year on linux-scsi/LKML, it has actually been developed *on* linux-scsi, patch by patch in full view of the configfs maintainer and other interested parties. This is the reason why the v4.0 code has progressed as fast as it has; a constant feedback loop from upstream developers who have been involved since the start of the development process. By virtue of this fact, we where able to make some early design decisions based on feedback from the community from the original proposed design and running prototype code. So, while I can very much apperciate Boaz's desire to attempt to reconcile the relationship between myself + other TCM/LIO developers with the SCST development community, but I don't think this will happen without a definate change to the SCST development workflow and interaction with 'outside of project' developers. --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
