From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 08:42:38 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 B2F4016A4BF; Mon, 25 Aug 2003 08:42:38 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7830543F85; Mon, 25 Aug 2003 08:42:37 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h7PFgZ6X093337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 25 Aug 2003 11:42:36 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h7PFgXIV093334; Mon, 25 Aug 2003 11:42:33 -0400 (EDT) (envelope-from wollman) Date: Mon, 25 Aug 2003 11:42:33 -0400 (EDT) From: Garrett Wollman Message-Id: <200308251542.h7PFgXIV093334@khavrinen.lcs.mit.edu> To: David Schultz In-Reply-To: <20030824230439.GA4954@HAL9000.homeunix.com> References: <200308181854.h7IIshJg098625@apollo.backplane.com> <20030824230439.GA4954@HAL9000.homeunix.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: re@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: Mon, 25 Aug 2003 15:42:38 -0000 < 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? -GAWollman