Re: path_lookup() alternative

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Jan 23, 2012 at 05:19:24AM -0500, dmitry.krivenok@emc.com wrote:
> Hello,
> I sent this question to Al Viro first, but didn't get any feedback, so reposting here and hope that someone can help me.
> 
> I'm trying to build existing system consisting of several kernel modules and user-space tools on the latest vanilla kernel.
> Previously, we used path_lookup() function to perform lookup with arbitrary flags (e.g. we passed LOOKUP_PARENT in
> some cases) and save results in nameidata structure. Then, this structure was passed to other kernel functions (e.g. 
> lookup_hash and then lookup_one_len) or was used directly in the module code.

lookup_one_len() does not take nameidata at all.
lookup_hash() is not only not exported, it's _static_.

what are you talking about?

> The problem is that path_lookup() was removed in c9c6cac0c2bdbda42e7b804838648d0bc60ddb13 and kern_path_parent
> was added instead (and, of course, it didn't allow user to pass arbitrary flags).
> Then, in e3c3d9c838d48c0341c40ea45ee087e3d8c8ea39, kern_path_parent() was unexported and thus became unavailable for us.
> 
> I spent several hours learning path lookup code in the kernel tree, but didn't find a function/method which allows to get properly filled 
> nameidata having only path and flags.
> Is there an alternative to removed path_lookup() function or any other way of {path, flags}->{nameidata} translation?

Depends on what do you want to do with it.  IMO nameidata should be internal to
fs/namei.c; we still have it exposed more than I'd like it to be and if nothing
else, that exposure is going to shrink.

Details of your use case, please (ideally - along with the reference to your
code).