Christoph Hellwig: > Strong NACK to all these exports, no one has any buesiness looking at > these. Will you tell me why? If you have ever discussed exporting lookup_hash(), then please tell me its URL or something. lookup_hash is necessary for aufs since, (from the mail "Subject: [RFC Aufs2 #5 01/29] aufs documents") +Lookup in a Branch +---------------------------------------------------------------------- +Since aufs has a character of sub-VFS (see Introduction), it operates +lookup for branches as VFS does. It may be a heavy work. Generally +speaking struct nameidata is a bigger structure and includes many +information. But almost all lookup operation in aufs is the simplest +case, ie. lookup only an entry directly connected to its parent. Digging +down the directory hierarchy is unnecessary. + +VFS has a function lookup_one_len() for that use, but it is not usable +for a branch filesystem which requires struct nameidata. So aufs +implements a simple lookup wrapper function. When a branch filesystem +allows NULL as nameidata, it calls lookup_one_len(). Otherwise it builds +a simplest nameidata and calls lookup_hash(). +Here aufs applies "a principle in NFSD", ie. if the filesystem supports +NFS-export, then it has to support NULL as a nameidata parameter for +->create(), ->lookup() and ->d_revalidate(). So the lookup wrapper in +aufs tests if ->s_export_op in the branch is NULL or not. 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