summaryrefslogtreecommitdiff
path: root/fs/mount.h
AgeCommit message (Collapse)Author
2012-01-03vfs: now it can be done - make mnt_parent point to struct mountAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: mnt_parent moved to struct mountAl Viro
the second victim... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: spread struct mount - mnt_has_parentAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: the first spoils - mnt_hash movedAl Viro
taken out of struct vfsmount into struct mount Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: spread struct mount - __lookup_mnt() resultAl Viro
switch __lookup_mnt() to returning struct mount *; callers adjusted. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: start hiding vfsmount guts seriesAl Viro
Almost all fields of struct vfsmount are used only by core VFS (and a fairly small part of it, at that). The plan: embed struct vfsmount into struct mount, making the latter visible only to core parts of VFS. Then move fields from vfsmount to mount, eventually leaving only mnt_root/mnt_sb/mnt_flags in struct vfsmount. Filesystem code still gets pointers to struct vfsmount and remains unchanged; all such pointers go to struct vfsmount embedded into the instances of struct mount allocated by fs/namespace.c. When fs/namespace.c et.al. get a pointer to vfsmount, they turn it into pointer to mount (using container_of) and work with that. This is the first part of series; struct mount is introduced, allocation switched to using it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03vfs: new internal helper: mnt_has_parent(mnt)Al Viro
vfsmounts have ->mnt_parent pointing either to a different vfsmount or to itself; it's never NULL and termination condition in loops traversing the tree towards root is mnt == mnt->mnt_parent. At least one place (see the next patch) is confused about what's going on; let's add an explicit helper checking it right way and use it in all places where we need it. Not that there had been too many, but... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>