On Sun, 26 Dec 2010 16:45:51 -0500 "Theodore Ts'o" <tytso@xxxxxxx> wrote: > In the inode operations functions lookup() and rename(): > > struct dentry * (*lookup)(struct inode *inode, > struct dentry *dentry, > struct nameidata *nd); > > int (*rename)(struct inode *old_dir, struct dentry *old_dentry, > struct inode *new_dir, struct dentry *new_entry); > > ... is the fact that we pass in the inode superfluous? > > i.e., it looks like in all cases one can obtain the inode by looking at > dentry->d_parent. Or am I missing something? > I'd guess that it is "historical reasons". Some times it isn't safe to de-reference ->d_parent without extra locking (via dget_parent) so there could be cases where passing an already-ref-counted pointer might be cleaner, but during lookup and rename there must be sufficient locking so that ->d_parent cannot change. So all you could gain by passing the pointer separately is avoiding a single memory reference. As d_parent is almost certainly in cache when these are called, that would not be a big gain. It might be worth checking that the code doesn't get bigger if you drop the arg and use ->d_parent instead, but assuming it doesn't (which seems likely), I would agree that passing the parent inode explicitly is unnecessary. NeilBrown -- 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
