From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [patch] vfs: create /proc//mountinfo Date: Thu, 31 Jan 2008 10:45:23 -0800 Message-ID: <1201805123.10358.23.camel@ram.us.ibm.com> References: <20080130160839.828c4363.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@ftp.linux.org.uk, a.p.zijlstra@chello.nl To: Miklos Szeredi Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:49856 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759674AbYAaSrU (ORCPT ); Thu, 31 Jan 2008 13:47:20 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2008-01-31 at 10:17 +0100, Miklos Szeredi wrote: > > > From: Ram Pai ...snipped... > 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 code. > > > 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. RP > > 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