From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 05:17:02 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB04A16A4CE; Wed, 5 Jan 2005 05:17:02 +0000 (GMT) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24DE443D39; Wed, 5 Jan 2005 05:17:02 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j055H0JG013754 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Jan 2005 16:17:01 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j055H0xP038476; Wed, 5 Jan 2005 16:17:00 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j055H0Ut038475; Wed, 5 Jan 2005 16:17:00 +1100 (EST) (envelope-from pjeremy) Date: Wed, 5 Jan 2005 16:17:00 +1100 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20050105051700.GJ34222@cirb503493.alcatel.com.au> References: <20050104224043.GM784@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050104224043.GM784@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2i cc: arch@freebsd.org cc: scottl@freebsd.org Subject: Re: BigDisk project: du(1) 64bit clean. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 05:17:02 -0000 On Tue, 2005-Jan-04 23:40:43 +0100, Pawel Jakub Dawidek wrote: >I want you to look at two patches which makes du(1) 64bit clean. You might also like to look at the thread beginning http://lists.freebsd.org/pipermail/freebsd-hackers/2004-December/009427.html > http://people.freebsd.org/~pjd/patches/fts.h.patch > >It adds 64bit fts_bignum field, but because it is hiden under union, >it doesn't break ABI. It also doesn't break API, thanks to #defines. Very nice. Much cleaner than my suggestions. All of our supported architectures are either I32LP64 or ILP32 (ignoring bde's IP32L64 i386 variant) therefore the union won't affect alignment or alter padding. Since NULL is physically represented by all zero bits on all our architectures, fts_bignum is even correctly initialised to zero - though this bit isn't standards compliant. >We should decide if we want fts.h.patch also in HEAD or only in RELENG_5, >because we can make it much cleaner in HEAD, but we will break ABI >(API should be quite ok) - we need to change size of fts_number field. I gather you're suggesting that fts_number be changed to int64_t in HEAD. I'm less convinced about this - though if this change is made, it should be done sooner rather than later. The only downside is that ls(1) will bloat further on 32-bit architectures (I recall seeing at least one complaint about running ls on a ludicrously big directory). fts(3) is a BSD4.4 invention. The 4.x man page suggests future standardisation by POSIX but this statement disappeared in v1.14 without any comment in the commit logs. Rather than changing fts_number to int64, I suggest leaving the patch and documenting that fts_bignum overlays both fts_number and fts_pointer. The need for fts_bignum will probably disappear in time. -- Peter Jeremy