On Fri, Mar 25, 2011 at 1:18 AM, James Bottomley <James.Bottomley@xxxxxxx> wrote: > On Wed, 2011-03-23 at 23:59 -0700, Nicholas A. Bellinger wrote: >> On Thu, 2011-03-24 at 10:29 +0900, FUJITA Tomonori wrote: >> > On Wed, 23 Mar 2011 16:28:37 -0700 >> > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: >> > >> > > > Hmm, you prefer 'zero C userspace code'? On the other hand, you insist >> > > > that requiring user Python userspace code to set up ibmvscsis is a >> > > > better approach even when the kernel space can set up everything for >> > > > ibmvscsis? >> > > > >> > > >> > > Yes, because we expect userspace to drive creation of the current >> > > configfs group layout. >> > > >> > > The configfs maintainer explictly requested to drop the ability to drive >> > > the config_group creation from kernel-space that I had implemented >> > > originally, and which has not been included in the mainline target v4.0 >> > > control plane. >> > > >> > > It's folks like Joel and Greg-KH that need to be convinced in order for >> > > me to consider this type of logic for for mainline target code. I do >> > >> > Can you stop insisting that configfs can't do that so the target core >> > can't do that? >> > >> >> That's certainly not what I am insisting upon. I am trying to explain >> that we currently have a configfs control plane that is native for >> target mode. >> >> In the last three years to get to this point, I have developed prototype >> code and asked upstream review for: >> >> *) Creating logic to drive configuration from kernel-space for configfs >> *) Tried at creating sysfs -> configfs symlinks for referencing target >> core backend devices >> >> So far both of these attempts at patches have been firmly rejected by >> the configfs and sysfs maintainers. >> >> I am not saying that configfs is the end-all for all generic target mode >> control plane, but what I am saying is that I have yet to see the code >> for a different control plane that makes me want to move the away from a >> 'native configfs' to 'a configfs/sysfs hyrbid', or something else all >> together for mainline target code. > > OK, so what about an upcall to userspace to create the necessary > directories? That could be driven by the kernel and still not require > any implementation in configfs. Hi James, I might have missed something, but which upcall mechanism are you referring to ? Personally I'm not fond of the upcall concept because as far as I can see any synchronous upcall mechanism can potentially be used to trigger lock inversions not detectable by the PROVE_LOCKING mechanism. Regarding kernel-space driven directory creation in configfs: I have been wondering whether it is possible to implement any configuration filesystem such that directories can be created synchronously from kernel space without triggering lock inversion. I don't see this as a configfs limitation but as an inherent limitation of a configuration filesystem. In a similar way a self-declarative kernel interface like sysfs has the limitation that it is not possible to add configfs-style configuration functionality without triggering lock inversion. Both sysfs and configfs have important advantages over mechanisms like ioctl() and netlink but there are some disadvantages too. 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
