Split up struct nameidata into struct vfs_lookup with the lookup result
and intent and the remaining fields for performing an actual lookup.
Signed-off-by: Andreas Gruenbacher <[email protected]>
---
include/linux/namei.h | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -14,14 +14,14 @@ struct open_intent {
enum { MAX_NESTED_LINKS = 8 };
-struct nameidata {
- struct dentry *dentry;
+struct path {
struct vfsmount *mnt;
- struct qstr last;
+ struct dentry *dentry;
+};
+
+struct vfs_lookup {
+ struct path path;
unsigned int flags;
- int last_type;
- unsigned depth;
- char *saved_names[MAX_NESTED_LINKS + 1];
/* Intent data */
union {
@@ -29,9 +29,12 @@ struct nameidata {
} intent;
};
-struct path {
- struct vfsmount *mnt;
- struct dentry *dentry;
+struct nameidata {
+ struct vfs_lookup lookup;
+ struct qstr last;
+ int last_type;
+ unsigned depth;
+ char *saved_names[MAX_NESTED_LINKS + 1];
};
/*
On Wed, Aug 08, 2007 at 07:16:23PM +0200, Andreas Gruenbacher wrote:
> Split up struct nameidata into struct vfs_lookup with the lookup result
> and intent and the remaining fields for performing an actual lookup.
Looks good as a start, but please don't put a struct path in there,
as the vfsmount will go away from the lookup intent as soon as we have
a new inode operation for atomic create + open, and not having it in the
struct path will make that removal a lot less painfull.
> On Wed, Aug 08, 2007 at 07:16:23PM +0200, Andreas Gruenbacher wrote:
> > Split up struct nameidata into struct vfs_lookup with the lookup result
> > and intent and the remaining fields for performing an actual lookup.
>
> Looks good as a start, but please don't put a struct path in there,
> as the vfsmount will go away from the lookup intent as soon as we have
> a new inode operation for atomic create + open, and not having it in the
> struct path will make that removal a lot less painfull.
Btw, is the atomic open/create/truncate operation any further than
conceptual phase? Have we worked out what to do with the ugly "create
follows symlink" case?
I'm just about to add another hack to the VFS to enable atomic
open+truncate for fuse, and have a feeling that it will provoke some
not so positive reactions ;)
Miklos
On Wed, 08 August 2007, Christoph Hellwig wrote:
> On Wed, Aug 08, 2007 at 07:16:23PM +0200, Andreas Gruenbacher wrote:
> > Split up struct nameidata into struct vfs_lookup with the lookup result
> > and intent and the remaining fields for performing an actual lookup.
>
> Looks good as a start, but please don't put a struct path in there,
> as the vfsmount will go away from the lookup intent as soon as we have
> a new inode operation for atomic create + open, and not having it in the
> struct path will make that removal a lot less painfull.
Removing the vfsmount from struct vfs_intent sounds like a bad idea to
me. (dentry, vfsmount) pairs should be kept together; this makes it much
more obvious what's going on.
The idea of struct vfs_lookup is not a filesystem level abstraction and
information hiding mechanism, it is to be able to pass on a lookup
result to the vfs more easily. The vfsmount is definitely part of that
result. Cleaning up atomic create + open should be mostly independent of
that.
Attached are patches that introduce pathput() and pathget(). Those are
further cleanups which depend on the struct path in the nameidata /
vfs_lookup.
Thanks,
Andreas