From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ulrich Drepper" Subject: Re: [d_path 0/7] Fixes to d_path: Respin Date: Sat, 21 Apr 2007 12:46:34 -0700 Message-ID: References: <20070412090809.917795000@suse.de> <200704201840.07247.agruen@suse.de> <200704212104.06349.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alan Cox" , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, chrisw@sous-sol.org, "Andrew Morton" To: "Andreas Gruenbacher" Return-path: Received: from wr-out-0506.google.com ([64.233.184.226]:61207 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752068AbXDUTqf (ORCPT ); Sat, 21 Apr 2007 15:46:35 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1185332wra for ; Sat, 21 Apr 2007 12:46:34 -0700 (PDT) In-Reply-To: <200704212104.06349.agruen@suse.de> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 4/21/07, Andreas Gruenbacher wrote: > What I described is a supported feature, nothing more and nothing less. It's > also relatively easy to handle this case correctly in glibc, e.g., [...] This is only useful if the requirement of an ordered /proc/mounts is part of the kernel ABI. I.e., until somebody specifies (in the sources, in kernel docs, I don't care where exactly) that the entries in /proc/mounts appear in the order in which the mounts happened this change is not better than the current code. I have never found such an assurance. > This is what POSIX says about statvfs / fstatvfs: > > It is unspecified whether all members of the statvfs structure have > > meaningful values on all file systems. Sure, just like POSIX in many other place leaves things unspecified. This does not change the fact that we do a good job now. You try to use this wording to excuse the fact that you want to make the results worse than they are now. That's *not* the intend of this wording. > In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts > by far outweighs the problems is sometimes causes for fstatvfs(). Hell no. It is never acceptable to deliberately break compatibility. Effects of bugs on the ABI might change but this is not the case here. This is an interface which forever displayed the information in this form and it is correct and useful.