mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Shaya Potter <spotter@cs.columbia.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: permission() operating on inode instead of dentry?
Date: Wed, 28 May 2003 06:48:05 +0100	[thread overview]
Message-ID: <20030528054804.GF27916@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <1054099180.6942.71.camel@zaphod>

On Wed, May 28, 2003 at 01:19:40AM -0400, Shaya Potter wrote:
> [please cc: responses to me, have 10k message backlog in l-k folder)
> 
> Is there a good reason why the fs permission function operates on the
> inode instead of the dentry? It would seem if the dentry was passed into
> the function instead of the inode, one would have a better structure to
> play with, such as being able to use d_put() to get the real path name. 
> The inode is still readily accessible from the dentry.

man grep.

Then use the resulting knowledge to find the callers of said function in
the tree.

Then think where you would get dentry (and vfsmount, since you want path)
for each of these.  Exclude ones that have them available.  See which
functions contain the rest of calls.

Repeat the entire thing for each of these functions, until the set is
empty.  At that point you have a sequence of changes that need to be
done.  Start moving from the end of list, changing the prototypes and
updating callers.  You will get a sequence of patches ending with
what you want.  Look at their sizes.  If they are tolerably small and
straightforward - start posting them to fsdevel, one by one.  With
summaries.  Start with posting the list of changes (step 1 propagates
..., step 2...,  step n gives what we want).

Get that stuff merged, one by one.  Since it won't go in one release,
repeat the searches to verify that your analysis is still correct and
no new paths had appeared.

That's how it's done - there's nothing more to it.  And yes, this one
will end up in a moderately long chain of patches - it appeared to be
doable the last time I'd looked, but would result in 10-15 steps _if_
nothing tricky would crop up.

  reply	other threads:[~2003-05-28  5:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-28  5:19 Shaya Potter
2003-05-28  5:48 ` viro [this message]
2003-05-28  5:56   ` Shaya Potter

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=20030528054804.GF27916@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spotter@cs.columbia.edu \
    /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

all inboxes | Powered by JetHome®