Few weeks ago, I noticed that fs/namei.c defines struct path:
struct path {
struct vfsmount *mnt;
struct dentry *dentry;
};
I think it would make sense to move it into include/linux/ as it is quite
useful (and it would discourage the (ab)use of struct nameidata.)
The fsstack code could benefit from it as the stackable fs dentries have to
keep track of the lower dentry as well as the lower vfsmount.
One, rather unfortunate, fact is that struct path is also defined in
include/linux/reiserfs_fs.h as something completely different - reiserfs
specific.
Any thoughts?
Josef "Jeff" Sipek.
--
I already backed up the box once, I can do it again.
On Wed, 18 Oct 2006 00:23:23 -0400
Josef Sipek <[email protected]> wrote:
> Few weeks ago, I noticed that fs/namei.c defines struct path:
>
> struct path {
> struct vfsmount *mnt;
> struct dentry *dentry;
> };
>
> I think it would make sense to move it into include/linux/ as it is quite
> useful (and it would discourage the (ab)use of struct nameidata.)
>
> The fsstack code could benefit from it as the stackable fs dentries have to
> keep track of the lower dentry as well as the lower vfsmount.
>
> One, rather unfortunate, fact is that struct path is also defined in
> include/linux/reiserfs_fs.h as something completely different - reiserfs
> specific.
>
> Any thoughts?
>
reiserfs is being bad. s/path/reiserfs_path/g
On Wed, Oct 18, 2006 at 01:31:03AM -0700, Andrew Morton wrote:
> On Wed, 18 Oct 2006 00:23:23 -0400
> Josef Sipek <[email protected]> wrote:
>
> > Few weeks ago, I noticed that fs/namei.c defines struct path:
> >
> > struct path {
> > struct vfsmount *mnt;
> > struct dentry *dentry;
> > };
> >
> > I think it would make sense to move it into include/linux/ as it is quite
> > useful (and it would discourage the (ab)use of struct nameidata.)
> >
> > The fsstack code could benefit from it as the stackable fs dentries have to
> > keep track of the lower dentry as well as the lower vfsmount.
> >
> > One, rather unfortunate, fact is that struct path is also defined in
> > include/linux/reiserfs_fs.h as something completely different - reiserfs
> > specific.
> >
> > Any thoughts?
> >
>
> reiserfs is being bad. s/path/reiserfs_path/g
Indeed. That's one pending patch that never got around to be submitted
(and had bitrotten at least 3 times, IIRC).
ACK, provided that reiserfs folks are OK with the replacement name for
their struct. Note that "path" in question has very little to do with
pathnames - it's a path in balanced tree, IIRC. So if we get around
to renaming that sucker, it might be a good time to pick better name.
Certainly ACK for generic part.
On Wed, 18 Oct 2006 01:31:03 -0700
Andrew Morton <[email protected]> wrote:
> > One, rather unfortunate, fact is that struct path is also defined in
> > include/linux/reiserfs_fs.h as something completely different - reiserfs
> > specific.
> >
> > Any thoughts?
> >
>
> reiserfs is being bad. s/path/reiserfs_path/g
There's also drivers/md/dm-mpath.h's struct path. Renaming fs/namei.c's
`struct path' to `struct namei_path' would be prudent.
On Wed, Oct 18, 2006 at 01:35:51AM -0700, Andrew Morton wrote:
> On Wed, 18 Oct 2006 01:31:03 -0700
> Andrew Morton <[email protected]> wrote:
>
> > > One, rather unfortunate, fact is that struct path is also defined in
> > > include/linux/reiserfs_fs.h as something completely different - reiserfs
> > > specific.
> > >
> > > Any thoughts?
> > >
> >
> > reiserfs is being bad. s/path/reiserfs_path/g
>
> There's also drivers/md/dm-mpath.h's struct path. Renaming fs/namei.c's
> `struct path' to `struct namei_path' would be prudent.
Yuck... If we really want to switch to it (and I can give you a dozen
examples of possible users right now - starting with struct file), putting
namei_ into it is both uninformative and ugly.
I'm not sure what would be the good name here; "pathname" comes to mind,
but it suggests that we are dealing with a string. And "location" is
too vague (and probably would cause fsckloads of conflicts itself).
Suggestions? "pathname" would almost work; the difference is that this
is not a string but a node in tree that string resolves to.
On Wed, 18 Oct 2006 10:06:23 +0100
Al Viro <[email protected]> wrote:
> On Wed, Oct 18, 2006 at 01:35:51AM -0700, Andrew Morton wrote:
> > On Wed, 18 Oct 2006 01:31:03 -0700
> > Andrew Morton <[email protected]> wrote:
> >
> > > > One, rather unfortunate, fact is that struct path is also defined in
> > > > include/linux/reiserfs_fs.h as something completely different - reiserfs
> > > > specific.
> > > >
> > > > Any thoughts?
> > > >
> > >
> > > reiserfs is being bad. s/path/reiserfs_path/g
> >
> > There's also drivers/md/dm-mpath.h's struct path. Renaming fs/namei.c's
> > `struct path' to `struct namei_path' would be prudent.
>
> Yuck... If we really want to switch to it (and I can give you a dozen
> examples of possible users right now - starting with struct file), putting
> namei_ into it is both uninformative and ugly.
>
> I'm not sure what would be the good name here; "pathname" comes to mind,
> but it suggests that we are dealing with a string. And "location" is
> too vague (and probably would cause fsckloads of conflicts itself).
>
> Suggestions? "pathname" would almost work; the difference is that this
> is not a string but a node in tree that string resolves to.
path_item?
On Wed, Oct 18, 2006 at 02:12:22AM -0700, Andrew Morton wrote:
> > Yuck... If we really want to switch to it (and I can give you a dozen
> > examples of possible users right now - starting with struct file), putting
> > namei_ into it is both uninformative and ugly.
> >
> > I'm not sure what would be the good name here; "pathname" comes to mind,
> > but it suggests that we are dealing with a string. And "location" is
> > too vague (and probably would cause fsckloads of conflicts itself).
> >
> > Suggestions? "pathname" would almost work; the difference is that this
> > is not a string but a node in tree that string resolves to.
>
> path_item?
struct path_node, perhaps?
> struct path_node
or just struct pathnode ?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
On Wed, Oct 18, 2006 at 02:27:47AM -0700, Paul Jackson wrote:
> > struct path_node
>
> or just struct pathnode ?
as long as it's not path_thingy (or path_turnip)...
On Wed, 18 October 2006 10:34:33 +0100, Al Viro wrote:
>
> as long as it's not path_thingy (or path_turnip)...
dpath?
J?rn
--
A victorious army first wins and then seeks battle.
-- Sun Tzu
On Wed, Oct 18, 2006 at 09:35:27AM +0100, Al Viro wrote:
> On Wed, Oct 18, 2006 at 01:31:03AM -0700, Andrew Morton wrote:
> > > One, rather unfortunate, fact is that struct path is also defined in
> > > include/linux/reiserfs_fs.h as something completely different - reiserfs
> > > specific.
> > >
> > > Any thoughts?
> > >
> >
> > reiserfs is being bad. s/path/reiserfs_path/g
>
> Indeed. That's one pending patch that never got around to be submitted
> (and had bitrotten at least 3 times, IIRC).
>
> ACK, provided that reiserfs folks are OK with the replacement name for
> their struct. Note that "path" in question has very little to do with
> pathnames - it's a path in balanced tree, IIRC. So if we get around
> to renaming that sucker, it might be a good time to pick better name.
Aside from having to reindent the reiserfs tree afterwards, I doubt
anyone would mind (please cc reiserfs-dev on the patch though). Al is
right, it's a path in the balanced tree.
-chris
IMHO, the string "path" is so generic (and nice, short, and sweet :-), that
only higher-level layers such as the VFS should be allowed to define it.
All other layers that are somewhere below the VFS (drivers/md/dm-mpath.h and
reiserfs), should rename their struct path to something more specific. If
anyone component can claim "first rights" for the name "struct path" -- it's
the VFS.
That said, 'pathnode' is also good, esp. if it better describes the contents
and use of this struct. But I would still rename all other uses of 'struct
path' below the VFS.
Erez.