Re: + embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.pa tch added to -mm tree

[Jan Blunck <jblunck@suse.de>]

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@suse.de>
> > 
> > Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.
> > 
> > Signed-off-by: Jan Blunck <jblunck@suse.de>
> > Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
> > Acked-by: Christoph Hellwig <hch@lst.de>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > CC: <linux-fsdevel@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Frowned-upon-by: Joern Engel <joern@logfs.org>
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html