kernel concepts: confusing dentry & nameidata

The dentry itself is at first not easy to catch on of its concept within VFS. On one hand, it doesn't like superblock, inode and alike structures, which maps directly to the physical disk image. On the other hand, it also doesn't like file, vfsmount structures, which even though without physical mapping, but they do have direct process activities relationship - such as open / mount. That is to say, dentry isn't a concept at a surface level where human can catch at first sight.

The dentry is used for the pathname resolution. However, during the pathname resolution procedure, path_lookup or do_path_lookup, there is actually another structure involved: struct nameidata. They are confusing at first, indeed.

Their major differences are (not clearly stated in books / articles I've read):

The variables for nameidata are always temporary and locally declared, used during the pathname resolution, even though we can see their pointers being passed here and there. There's no such thing of kmalloc or kmem_cache_alloc for them.

On the other hand, the dentry variables are global entities. Even though they are generated dynamically during the pathname lookup procedure, they are not randomly specified. If we look up first the file: /aa/bb/cc.txt, afterwards the file: /aa/bb/dd.txt, then the dentry for 'bb' will be exactly the same object for both lookup: first time by d_alloc to get a new dentry, afterwards by d_lookup to get that same object.

Another important mission: since inode struct objects are unnamed entities, to associate them with their proper name, it is within kernel by the dentry object to provide this liaison - by d_inode field.