Re: HEADS UP! MAJOR change to FreeBSD/sparc64

From: Craig Boston (craig_at_xfoil.gank.org)
Date: 03/15/04

  • Next message: Mark Johnston: "cvs-src summary for 14/03/04" 
    To: freebsd-current@freebsd.org
Date: Sun, 14 Mar 2004 23:17:09 -0600

    On Sunday 14 March 2004 08:12 pm, Garance A Drosihn wrote:
    > In the case of i386, there is a 10-year history of servers and
    > programs running with 32-bTT, in production. I do also run
    > freebsd/i386, and for that platform I really can not imagine making
    > this major a change without providing backward-compatibility. There
    > is just too much written which assumes 32-bTT, including programs
    > which perhaps can not be recompiled. I do not see that happening
    > before the 6.0-branch.

    FWIW, 64-bTT on i386 is something I've been playing with some in my spare
    time, and IMHO it's an even bigger headache than on sparc64. The ABI
    compatibility thing itself isn't a huge issue -- there are a couple of
    approaches involving compatibility syscalls / libc hacks. Not exactly
    trivial, but it's doable.

    The biggest problem on i386 is that there's a lot of third party software out
    there that misbehaves if sizeof(time_t) > sizeof(long), even when recompiled
    from source. I don't think this an issue on sparc64/amd64 -- IIRC long is
    already 64 bits on those platforms. Only real solutions I can think of at
    the moment are:

    1. Go 64-bit for longs on i386. I've seen scattered murmurings that this is
    possible with the current sources and a few folks run systems this way. I'm
    pretty sure there's no way to do this without completely breaking the ABI.
    Maybe if it coincided with a major libc version bump, and a compat ABI in the
    kernel, with new ELF branding for the 64-bit binaries... Maybe. It could
    also have an appreciable performance hit, though those who have been
    experimenting with it would know more than I how severe it is.

    2. Bite the bullet and fix all the broken software. This is probably the
    'correct' approach. I don't know exactly which specs (POSIX? C99?) apply,
    but I'm under the impression that no guarantee is made about the size of
    time_t relative to other basic types. If someone knows for sure, please
    correct me. This means lots and lots and lots of patches in the ports tree.
    Even with submitting them back, quite a few would have to be held locally as
    some authors may not care to fix it until Linux does the same thing and
    forces the issue. As a workaround, maybe there could be a flag in ports for
    '64-bit time_t clean'. If it's not set, some magic could kick in and build
    the port with a 32-bit time_t (activating whatever compat mechanism we have
    in place for old binaries).

    3. Do nothing on i386. Everybody should have a shiny new ÜberHammer 256-bit
    CPU by 2038, right? ;-)

    Craig
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Mark Johnston: "cvs-src summary for 14/03/04"

    Relevant Pages

    • Re: some PRs
      ... > In general, I'm not against compatibility. ... FreeBSD, but I know you have a Ports Collection with thousands of packages, ... (Note this patch comes from the context of the Debian GNU/kFreeBSD porting ... effort, in which we port Debian GNU/Linux packages, which are a bit more ...
      (freebsd-arch)
    • Re: HEADSUP: arp-v2 has been committed
      ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
      (freebsd-current)
    • Re: HEADSUP: arp-v2 has been committed
      ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
      (freebsd-net)
    • Re: [INFO] Kernel strict versioning
      ... As long as we want to guarantee abi, we must use the same names. ... > Get the module into the kernel. ... on compatibility with the ``major second number''. ...
      (Linux-Kernel)
    • RE: HEADSUP: arp-v2 has been committed
      ... Right now I am also a bit leaning towards reintroducing ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ...
      (freebsd-current)