From: "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
To: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org,
akpm@linux-foundation.org, viro@ftp.linux.org.uk,
Trond.Myklebust@netapp.com, neilb@suse.de, mhalcrow@us.ibm.com
Subject: [PATCH 0/4] [RFC] New path lookup function
Date: Sat, 5 May 2007 19:09:30 -0400 [thread overview]
Message-ID: <11784065741163-git-send-email-jsipek@cs.sunysb.edu> (raw)
Stackable file systems, among others, frequently need to lookup paths or
path components starting from an arbitrary point in the namespace
(identified by a dentry and a vfsmount). Currently, such file systems use
lookup_one_len, which is frowned upon [1] as it does not pass the lookup
intent along; not passing a lookup intent, for example, can trigger BUG_ON's
when stacking on top of NFSv4.
The first patch introduces a new lookup function to allow lookup starting
from an arbitrary point in the namespace. This approach has been suggested
by Christoph Hellwig [2].
The second patch changes sunrpc to use path_component_lookup.
The third patch changes nfsctl.c to use path_component_lookup.
The fourth, and last patch, unexports path_walk because it is no longer
unnecessary to call it directly, and using the new path_component_lookup is
cleaner.
For example, the following snippet of code, looks up "some/path/component"
in a directory pointed to by parent_{dentry,vfsmnt}:
err = path_component_lookup(parent_dentry, parent_vfsmnt,
"some/path/component", 0, &nd);
if (!err) {
/* exits */
...
/* once done, release the references */
path_release(&nd);
} else if (err == -ENOENT) {
/* doesn't exist */
} else {
/* other error */
}
VFS functions such as lookup_create can be used on the nameidata structure
to pass the create intent to the file system.
Currently, there is no easy way to pass the LOOKUP_OPEN intent. The proper
way would be to call open_namei.
We'd like to get comments about what's necessary to make stackable file
systems do lookups right: this includes potential changes to open_namei.
Josef 'Jeff' Sipek.
[1] http://lkml.org/lkml/2007/3/9/95
[2] http://lkml.org/lkml/2007/5/4/51
next reply other threads:[~2007-05-05 23:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-05 23:09 Josef 'Jeff' Sipek [this message]
2007-05-05 23:09 ` [PATCH 1/4] fs: Introduce path_component_lookup Josef 'Jeff' Sipek
2007-05-06 11:14 ` Christoph Hellwig
2007-05-05 23:09 ` [PATCH 2/4] sunrpc: Use path_component_lookup Josef 'Jeff' Sipek
2007-05-05 23:52 ` Trond Myklebust
2007-05-06 0:52 ` [PATCH 1/1] " Josef 'Jeff' Sipek
2007-05-06 14:46 ` Trond Myklebust
2007-05-05 23:09 ` [PATCH 3/4] nfsctl: " Josef 'Jeff' Sipek
2007-05-05 23:09 ` [PATCH 4/4] fs: Remove path_walk export Josef 'Jeff' Sipek
2007-05-06 11:15 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11784065741163-git-send-email-jsipek@cs.sunysb.edu \
--to=jsipek@cs.sunysb.edu \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
--cc=neilb@suse.de \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).