[PATCH v2 3/3] fs: store real path instead of fake path in backing file f_path

[Al Viro]

On Mon, Oct 09, 2023 at 11:25:38AM +0300, Amir Goldstein wrote:

> It's not important. I don't mind dropping it.
> 
> If you dislike that name f_path(), I guess you are not a fan of
> d_inode() either...

In case of d_inode() there's an opposition between d_inode() and
d_inode_rcu(), and that bears useful information.  In case of
f_path()...

> FYI, I wanted to do a file_path() accessor to be consistent with
> file_inode() and file_dentry(), alas file_path() is used for something
> completely different.
> 
> I find it confusing that {file,dentry,d}_path() do not return a path
> but a path string, but whatever.

*blink*

How would one possibly produce struct path (i.e. mount/dentry pair)
out of dentry?

Anyway, I admit that struct path hadn't been a great name to start with;
it's basically "location in namespace", and it clashes with the use of
the same word for "string interpreted to get a location in namespace".

Originally it's been just in the pathname resolution internals; TBH,
I don't remember I had specific plans regarding converting such
pairs (a plenty of those in the tree at the time) back then.
<checks the historical tree>
<checks old mail archives>

Probably hopeless to reconstruct the details, I'm afraid - everything
else aside, the timestamps in that patch are in the first half of
the day on Apr 29 2002; (hopefully) tested and sent out at about
6pm.  Followed by sitting down for birthday celebration, of all things,
so the details of rationale for name choice would probably be hard
to recover on the next morning, nevermind 21 years later ;-)

Bringing it out of fs/namei.c (into include/linux/namei.h) had happened
in late 2006 (by Jeff Sipek) and after that it was too late to change
the name; I'm still not sure what name would be good for that, TBH...