On Tue, Nov 06, Jörn Engel wrote:
> > 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.
>
> 400+ lines changed in this patch, some 10 in a followup patch that
> combines dentry/vfsmount assignments into a single path assignment. If
> your argument above was valid, I would expect more simplifications and
> fewer complications. Call me a sceptic until further patches show up to
> support your point.
This are the patches currently in -mm related to the struct path cleanup:
move-struct-path-into-its-own-header.patch
embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.patch
introduce-path_put.patch
use-path_put-in-a-few-places-instead-of-mntdput.patch
introduce-path_get.patch
use-struct-path-in-fs_struct.patch
make-set_fs_rootpwd-take-a-struct-path.patch
introduce-path_get-unionfs.patch
embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-unionfs.patch
introduce-path_put-unionfs.patch
one-less-parameter-to-__d_path.patch
d_path-kerneldoc-cleanup.patch
d_path-use-struct-path-in-struct-avc_audit_data.patch
d_path-make-proc_get_link-use-a-struct-path-argument.patch
d_path-make-get_dcookie-use-a-struct-path-argument.patch
use-struct-path-in-struct-svc_export.patch
use-struct-path-in-struct-svc_expkey.patch
d_path-make-seq_path-use-a-struct-path-argument.patch
d_path-make-d_path-use-a-struct-path.patch
> > It enables us
> > to do some more cleanups wrt lookup (which are coming later).
>
> Please send those patches. I invite cleanups that do clean things up
> and won't argue against then. ;)
I'll send them in a later series.
> > For stacking
> > support in VFS it is essential to have the <dentry,vfsmount> pair in every
> > place where you want to traverse the stack.
>
> True, but unrelated to this patch.
I start sending out the patches in multiple chunks because nobody reviewed the
union mount series except for coding style violations. So this is the prework
for the changes that come with my union mount series. So they are related
but not a part of the union mount patch series. It seems that people tend to
like the patch series with small changes for itself instead of a big fat
series.
> > I wonder why you didn't speak up when this series was posted to LKML. It was
> > at least posted three times before.
>
> I did speak up. Once. If you missed that thread, please forgive me
> missing those in which the same patch I disapproved of were resent
> without me on Cc.
Sorry for missing your feedback but now I found your mail ("mental
masturbation that complicates the source"). I guess this is what happens when
multiple people start posting the same patch series.
Coming back to the mental stuff: the savings of the first bunch of patches
that already hit -mm:
Textsize without patches: 0x20e572
Textsize with patches: 0x20e042
----------------------------------
0x530 = 1328 bytes
Cheers,
Jan
-
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
