From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [d_path 0/7] Fixes to d_path: Respin Date: Sun, 22 Apr 2007 10:10:33 +0100 Message-ID: <20070422091033.GA1558@infradead.org> References: <20070412090809.917795000@suse.de> <200704201840.07247.agruen@suse.de> <200704212104.06349.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ulrich Drepper , Alan Cox , jjohansen@suse.de, 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 pentafluge.infradead.org ([213.146.154.40]:37607 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965550AbXDVJKh (ORCPT ); Sun, 22 Apr 2007 05:10:37 -0400 Content-Disposition: inline In-Reply-To: <200704212104.06349.agruen@suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Apr 21, 2007 at 09:04:06PM +0200, Andreas Gruenbacher wrote: > > It is unspecified whether all members of the statvfs structure have > > meaningful values on all file systems. > > In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts > by far outweighs the problems is sometimes causes for fstatvfs(). Anyone > relying on the information obtained from statvfs / fstatvfs is making false > assumptions anyway, and in "normal setups" as you called them, nothing > changes for fstatvfs and statvfs. So what about stopping the flaming here and implementing real statvfs/ fstatvfs syscalls instead of these horrible hacks glibc has to do currently? Using our kstatfs infrastructure that should be dirt simple. arch/sparc64/solaris/fs.c already has a template of a statvfs syscall for solaris, although we could probably improve a little on that.