From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 21:39:17 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75A4616A4BF for ; Mon, 25 Aug 2003 21:39:17 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB67F43FDD for ; Mon, 25 Aug 2003 21:39:16 -0700 (PDT) (envelope-from das@freebsd.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h7Q4dFXR003405; Mon, 25 Aug 2003 21:39:15 -0700 (PDT) (envelope-from das@freebsd.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h7Q4dBhO003404; Mon, 25 Aug 2003 21:39:11 -0700 (PDT) (envelope-from das@freebsd.org) Date: Mon, 25 Aug 2003 21:39:11 -0700 From: David Schultz To: Garrett Wollman Message-ID: <20030826043911.GA3361@HAL9000.homeunix.com> Mail-Followup-To: Garrett Wollman , freebsd-current@freebsd.org References: <200308181854.h7IIshJg098625@apollo.backplane.com> <20030824230439.GA4954@HAL9000.homeunix.com> <200308251542.h7PFgXIV093334@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308251542.h7PFgXIV093334@khavrinen.lcs.mit.edu> cc: freebsd-current@freebsd.org Subject: Re: 64 bit quantities in statfs ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2003 04:39:17 -0000 On Mon, Aug 25, 2003, Garrett Wollman wrote: > < said: > > > Yep, looks broken. In the POSIX standard, the functionality of > > statfs() is provided by statvfs(), so implementing the latter may > > be a way out that doesn't involve breaking any ABIs. > > statfs() is a lot more useful interface than statvfs(). I'd like to > keep statvfs() as the ``standard'' interface, rather than extending it > to cover all of the information that statfs() has. > > In order to grow statfs() we need to rev libc. It might be > appropriate to do that in the 5.2 time frame, if we are still > anticipating that 5.2 will be the -stable crossover point. RE team? We can't fix statfs() until 6.0. statvfs() is potentially just as useful, and it doesn't suffer from the same problems. Despite being underspecified by the standard, many systems, e.g. Solaris, make it convey at least as much information as statfs().