ty den 09.08.2005 Klokka 22:42 (+0200) skreiv Miklos Szeredi: > Trond, wake up! __emul_lookup_dentry() does nothing of the sort. > Neither does anything else. In theory it could, but that's not a > reason to do a confusing thing like that.
Really? static int __emul_lookup_dentry(const char *name, struct nameidata *nd) { ..... if (path_walk(name, nd) == 0) { if (nd->dentry->d_inode) { dput(old_dentry); mntput(old_mnt); return 1; } path_release(nd); } nd->dentry = old_dentry; nd->mnt = old_mnt; nd->last = last; nd->last_type = last_type; } return 1; } Which is called by path_lookup(), which again returns success, and expects the user to call path_release() later. > > Firstly, the open_namei() flags field is not a "permissions" field. It > > contains open mode information. The calculation of the open permissions > > flags is done by open_namei() itself. > > Based on flags. It's just a FMODE_* -> MAY_* transformation > > > Secondly, what advantage is there in allowing callers of open_namei() to > > be able to override the MAY_WRITE check when doing open(O_TRUNC)? This > > is a calculation that should be done _once_ in order to always get it > > right, and it should therefore be done in open_namei() together with the > > rest of the permissions calculation. > > I think the _only_ caller of open_namei() is filp_open(), so this is > not much of an issue, but yeah, you could do it that way too. Currently, yes. The only caller of open_namei() is filp_open(). That was not always the case previously. If we think it will never be the case in the future, then there is an argument for merging the two and/or making open_namei() and inlined function. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html