"Aneesh Kumar K. V": > Now that we are not doing UUID based vfsmount lookup this make > sense. Will update in the next iteration with UUID to be part of > super_block. Because this UUID is just for some FS's userspace helpers (in other words, returning UUID is FS specific behaviour), I am afraid it is not a good ideat to put the array into generic super_block. About the design or approach, this might have been discussed earlier, but I'd like to suggest to clarify some points here. - While these new systemcalls provide generic features, the implementation depends upon s_export_op, ie. NFS-exporting. It means there are two requirements for these systemcalls, enabling CONFIG_EXPORTFS and FS has to set s_export_op. Is this acceptable? - exportfs_encode_fh() supports the default encoding export_encode_fh(), but exportfs_decode_fh() doesn't. The latest patch series modifes exportfs_decode_fh() to return ESTALE, but I'd suggest to make the caller of export_encode_fh() to check s_export_op->fh_to_dentry() and return ENOSYS. Or implement the default decode routine as a contrast of export_encode_fh(). - Some FS (or its userspace helper) may want to put UUID into the handle. If those FS already have UUID in their fs private_data, then putting a pointer (instead of an array) is better. Or creating two new operations in s_op to encode/decode handle may be good too (regardless CONFIG_EXPORTFS). The generic implementations should be provided, and when these function pointers in s_op are not set, they should be called as default. These generic implementaions will be able to be used by expfs.c too. And UUID in super_block will be unnecessary. If my English is broken and hard to understand, please let me know. J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
