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: [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: Compatibility Between Releases Policy
      ... I recall reading once upon a time that FreeBSD won't break compatibility for the duration of a major point release. ... Ports astonish me more often than FreeBSD to be sure. ...
      (freebsd-questions)
    • Re: Wrapping a C++ library using ?FFI
      ... implementation of libstdc++ has some ABI issues between versions. ... I don't know exactly what you are talking about but inlined code cannot have any hope of binary compatibility. ... particularly brittle; it just takes more work to set up (esp. ... for some compilers). ...
      (comp.lang.lisp)
    • Re: some PRs
      ... >> In general, I'm not against compatibility. ... > should ask the people working in the Ports Collection for their opinion before ... > (Note this patch comes from the context of the Debian GNU/kFreeBSD porting ...
      (freebsd-arch)