LKML Archive on
help / color / mirror / Atom feed
From: Ram Pai <>
To: Miklos Szeredi <>
Subject: Re: [patch] vfs: create /proc/<pid>/mountinfo
Date: Thu, 31 Jan 2008 10:45:23 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 2008-01-31 at 10:17 +0100, Miklos Szeredi wrote:
> > > From: Ram Pai <>


> IDR ids are 'int' but they are always positive (AFAICT), but yeah,
> maybe this is confusing.
> > The new exported-to-everyone dentry_path() probably could do with a bit
> > more documentation - it's the sort of thing which people keep on wanting
> > and using.
> OK.
> > How does dentry_path() differ from d_path() and why do we need both and can
> > we get some sharing/consolidation happening here?

d_path displays the path from the rootfs, whereas dentry_path displays
the path from the root of that filesystem.

> Tried that but not easy, without removing some of the
> microoptimizations in d_path(), which I'm not sure are really
> important, but...

this patch was intially developed with Al Viro. He preferred to keep the
two functions separate. BTW: this patch owes credits to Al Viro for his
initial set of ideas.

> > Why do d_path() and dentry_path() have differing conventions for displaying
> > a deleted file and can we fix that?
> I think Ram chose a different convention in dentry_path() in order to
> make sure, there was no space in the resulting path.  But spaces would
> be escaped anyway, so this isn't really important.  So yes, this could
> be fixed.

my patch was generated about  a year or so back using probably the
2.6.18 code base which had the "//deleted" convention. That got copied
in my patch. But since then I see that the original code has changed to
use the " (deleted)" convention. 

Yes this patch has to be changed to be consistent with the existing

> > This patch adds a lot of code which is, I guess, unused if
> > CONFIG_PROC_FS=n.  Fixable?

yes. good observation. I will send a patch with this optimization and
the above mentioned change. 


> Possibly yes.  A good chunk of namespace.c could be surrounded by an
> #ifdef, which would save even more, than was added by this particular
> patch.

> Thanks,
> Miklos

  reply	other threads:[~2008-01-31 18:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 13:57 Miklos Szeredi
2008-01-31  0:08 ` Andrew Morton
2008-01-31  9:17   ` Miklos Szeredi
2008-01-31 18:45     ` Ram Pai [this message]
2008-02-04  9:15       ` [RFC PATCH] vfs: optimization to /proc/<pid>/mountinfo patch Ram Pai
2008-02-04  9:28         ` Andrew Morton
2008-02-11  7:36           ` Ram Pai
2008-02-04 11:49         ` Miklos Szeredi

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [patch] vfs: create /proc/<pid>/mountinfo' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).