On Mon, Nov 05, Jörn Engel wrote:
> > Subject: Embed a struct path into struct nameidata instead of nd->{dentry,mnt}
> > From: Jan Blunck <jblunck@xxxxxxx>
> >
> > Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.
> >
> > Signed-off-by: Jan Blunck <jblunck@xxxxxxx>
> > Signed-off-by: Andreas Gruenbacher <agruen@xxxxxxx>
> > Acked-by: Christoph Hellwig <hch@xxxxxx>
> > Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> > CC: <linux-fsdevel@xxxxxxxxxxxxxxx>
> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Frowned-upon-by: Joern Engel <joern@xxxxxxxxx>
>
> This patch changes some 400 lines, most if not all of which get longer
> and more complicated to read. 23 get sufficiently longer to require an
> additional linebreak. I can't remember complexity being invited into
> the kernel without good reasoning, yet the patch description is
> surprisingly low on reasoning:
> > Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.
I don't measure complexity by lines of code or length of lines. Maybe I was
not verbose enough in the description, fair.
This is a cleanup series. In mostly no case there is a reason why someone
would want to use a dentry for itself. This series reflects that fact in
nameidata where there is absolutly no reason at all. It enforced the correct
order of getting/releasing refcount on <dentry,vfsmount> pairs. It enables us
to do some more cleanups wrt lookup (which are coming later). For stacking
support in VFS it is essential to have the <dentry,vfsmount> pair in every
place where you want to traverse the stack.
> If churn is the only effect of this, please considere it NAKed again.
I wonder why you didn't speak up when this series was posted to LKML. It was
at least posted three times before.
Did I break your COW link patches? ;)
-
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
