Re: BigDisk project: du(1) 64bit clean.

From: Peter Jeremy (PeterJeremy_at_optushome.com.au)
Date: 01/05/05

  • Next message: Julian Elischer: "Re: BigDisk project: du(1) 64bit clean." 
    Date: Wed, 5 Jan 2005 16:17:00 +1100
To: Pawel Jakub Dawidek <pjd@freebsd.org>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: BigDisk project: du(1) 64bit clean."

    Relevant Pages

    • Re: BigDisk project: du(1) 64bit clean.
      ... > one of its structures to store size. ... we need this patch: ... > because we can make it much cleaner in HEAD, but we will break ABI ...
      (freebsd-arch)
    • BigDisk project: du(1) 64bit clean.
      ... So first of all, we need this patch: ... It also doesn't break API, ... 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 ...
      (freebsd-arch)