From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: vaurora@redhat.com, neilb@suse.de, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 2/6] vfs: make i_op->permission take a dentry instead of an inode
Date: Fri, 17 Sep 2010 18:44:09 +0530 [thread overview]
Message-ID: <m31v8stsv2.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100903134148.908403931@szeredi.hu>
On Fri, 03 Sep 2010 15:41:18 +0200, Miklos Szeredi <miklos@szeredi.hu> wrote:
> From: Miklos Szeredi <mszeredi@suse.cz>
>
> Like most other inode operations ->permission() should take a dentry
> instead of an inode. This is necessary for filesystems which operate
> on names not on inodes.
>
This change will also help 9P patch series i am doing
http://article.gmane.org/gmane.linux.kernel/1032788
Currently ACL values are fetched from the server as a part of inode
initialization. We can't do it in inode operations->permission because
we need dentry to do 9P operations. Having inode operations->permission
take a dentry instead of an inode help there.
-aneesh
next prev parent reply other threads:[~2010-09-17 13:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 13:41 [PATCH 0/6] overlay filesystem prototype Miklos Szeredi
2010-09-03 13:41 ` [PATCH 1/6] vfs: implement open "forwarding" Miklos Szeredi
2010-09-03 13:41 ` [PATCH 2/6] vfs: make i_op->permission take a dentry instead of an inode Miklos Szeredi
2010-09-17 13:14 ` Aneesh Kumar K. V [this message]
2010-09-03 13:41 ` [PATCH 3/6] vfs: add flag to allow rename to same inode Miklos Szeredi
2010-09-03 13:41 ` [PATCH 4/6] vfs: export do_splice_direct() to modules Miklos Szeredi
2010-09-03 13:41 ` [PATCH 5/6] overlay: hybrid overlay filesystem prototype Miklos Szeredi
2010-09-03 13:41 ` [PATCH 6/6] overlay: overlay filesystem documentation Miklos Szeredi
2010-09-05 10:37 ` [PATCH 0/6] overlay filesystem prototype J. R. Okajima
2010-09-05 11:44 ` Neil Brown
2010-09-05 12:08 ` J. R. Okajima
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=m31v8stsv2.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=vaurora@redhat.com \
--cc=viro@zeniv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.