64 bit time_t - FreeBSD

This is a discussion on 64 bit time_t - FreeBSD ; Other than recompiling for -current users (and not being an MFC-able change and possibly breaking a gazillion unfortunately written ports), are their any other issues with switching to 64 bit time_t for i386? I suppose compat libs are a bit ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: 64 bit time_t

  1. 64 bit time_t

    Other than recompiling for -current users (and not being an MFC-able
    change and possibly breaking a gazillion unfortunately written ports),
    are their any other issues with switching to 64 bit time_t for i386?
    I suppose compat libs are a bit dicey.
    _______________________________________________
    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"


  2. Re: 64 bit time_t

    On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote:
    > Other than recompiling for -current users (and not being an MFC-able
    > change and possibly breaking a gazillion unfortunately written ports),
    > are their any other issues with switching to 64 bit time_t for i386?
    > I suppose compat libs are a bit dicey.


    Off hand: every syscall that takes a time_t or a structure containing
    a time_t would have to be reimplemented and a compatability version
    provided in the old location. The same would be true of every similar
    function in the libc symbol map. A number of ioctl's and sysctl would
    probably need to grow compatability interfaces as well.

    -- Brooks

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (FreeBSD)

    iD8DBQFI0CI+XY6L6fI4GtQRAiCgAKDRrCB/zMXZnax/OXKR/g979hrUIwCgmo7y
    MdQtWAMGVKUqyiOaUBmmM5I=
    =LXp3
    -----END PGP SIGNATURE-----


  3. Re: 64 bit time_t

    In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis writes
    :
    >
    >--PEIAKu/WMn1b1Hv9
    >Content-Type: text/plain; charset=us-ascii
    >Content-Disposition: inline
    >
    >On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote:
    >> Other than recompiling for -current users (and not being an MFC-able
    >> change and possibly breaking a gazillion unfortunately written ports),
    >> are their any other issues with switching to 64 bit time_t for i386?
    >> I suppose compat libs are a bit dicey.

    >
    >Off hand: every syscall that takes a time_t or a structure containing
    >a time_t would have to be reimplemented and a compatability version[...]


    This is a pretty nasty piece of work because it also involves the
    timespec and timeval structures which appear in ioctls, socket
    options, socket messages and so on.

    --
    Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
    phk@FreeBSD.ORG | TCP/IP since RFC 956
    FreeBSD committer | BSD since 4.3-tahoe
    Never attribute to malice what can adequately be explained by incompetence.
    _______________________________________________
    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"


  4. Re: 64 bit time_t

    On Tuesday 16 September 2008 05:26:14 pm Poul-Henning Kamp wrote:
    > In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis

    writes
    > :
    > >
    > >--PEIAKu/WMn1b1Hv9
    > >Content-Type: text/plain; charset=us-ascii
    > >Content-Disposition: inline
    > >
    > >On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote:
    > >> Other than recompiling for -current users (and not being an MFC-able
    > >> change and possibly breaking a gazillion unfortunately written ports),
    > >> are their any other issues with switching to 64 bit time_t for i386?
    > >> I suppose compat libs are a bit dicey.

    > >
    > >Off hand: every syscall that takes a time_t or a structure containing
    > >a time_t would have to be reimplemented and a compatability version[...]

    >
    > This is a pretty nasty piece of work because it also involves the
    > timespec and timeval structures which appear in ioctls, socket
    > options, socket messages and so on.


    And with amd64/x86-64, it may prove to not really be necessary.

    --
    John Baldwin
    _______________________________________________
    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"


  5. Re: 64 bit time_t

    Poul-Henning Kamp wrote at 21:26 +0000 on Sep 16, 2008:
    > In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis writes
    > :
    > >
    > >--PEIAKu/WMn1b1Hv9
    > >Content-Type: text/plain; charset=us-ascii
    > >Content-Disposition: inline
    > >
    > >On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote:
    > >> Other than recompiling for -current users (and not being an MFC-able
    > >> change and possibly breaking a gazillion unfortunately written ports),
    > >> are their any other issues with switching to 64 bit time_t for i386?
    > >> I suppose compat libs are a bit dicey.

    > >
    > >Off hand: every syscall that takes a time_t or a structure containing
    > >a time_t would have to be reimplemented and a compatability version[...]

    >
    > This is a pretty nasty piece of work because it also involves the
    > timespec and timeval structures which appear in ioctls, socket
    > options, socket messages and so on.


    Okay. Sounds "fun".

    So for systems where we don't care about compatibility (where a
    product is built from scratch and we don't have to worry about 3rd
    party binary libs/programs), the problems mentioned by brooks & phk
    disappear.

    No one wants to play the performance or atomic access card?
    _______________________________________________
    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"


  6. Re: 64 bit time_t

    John Baldwin wrote at 10:40 -0400 on Sep 17, 2008:
    > And with amd64/x86-64, it may prove to not really be necessary.


    I'm not sure I understand the "may" part. Aren't we already using 64
    bit time_t natively on amd64? Or maybe you're talking about 32 bit
    compat on amd64.
    _______________________________________________
    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"


  7. Re: 64 bit time_t

    In message <18641.9074.499346.988999@gromit.timing.com>, John Hein writes:

    >So for systems where we don't care about compatibility (where a
    >product is built from scratch and we don't have to worry about 3rd
    >party binary libs/programs), the problems mentioned by brooks & phk
    >disappear.
    >
    >No one wants to play the performance or atomic access card?


    I know of only the kernel variable "time_second" where that would be
    a concern, and since we have 64bit atomic writes, I consider that
    a non-concern.

    At any rate, even if you write it with two 32bit writes, you will
    only have one chance for a race every 136 years.

    Next time you have the chance is:

    critter phk> bc
    bc 1.06
    Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
    This is free software with ABSOLUTELY NO WARRANTY.
    For details type `warranty'.
    2^31-1
    2147483647
    critter phk> date -r 2147483647
    Tue Jan 19 03:14:07 UTC 2038

    --
    Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
    phk@FreeBSD.ORG | TCP/IP since RFC 956
    FreeBSD committer | BSD since 4.3-tahoe
    Never attribute to malice what can adequately be explained by incompetence.
    _______________________________________________
    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"


  8. Re: 64 bit time_t

    On Tue, 16 Sep 2008 21:26:14 +0000, "Poul-Henning Kamp" wrote:
    >In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis writes
    >>On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote:
    >>> Other than recompiling for -current users (and not being an MFC-able
    >>> change and possibly breaking a gazillion unfortunately written ports),
    >>> are their any other issues with switching to 64 bit time_t for i386?
    >>> I suppose compat libs are a bit dicey.

    >>
    >> Off hand: every syscall that takes a time_t or a structure containing
    >> a time_t would have to be reimplemented and a compatability
    >> version[...]

    >
    > This is a pretty nasty piece of work because it also involves the
    > timespec and timeval structures which appear in ioctls, socket
    > options, socket messages and so on.


    Wire-formats for network protocols are also going to be lots of fun too.
    icmp4's and tcp4's timestamp options (and other wire-protocol formats)
    use uint32_t. Presumambly, by the time 32-bits are no longer enough
    these wire-protools will be replaced by their more modern versions.

    _______________________________________________
    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"


  9. Re: 64 bit time_t

    On Wednesday 17 September 2008 11:38:38 am John Hein wrote:
    > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008:
    > > And with amd64/x86-64, it may prove to not really be necessary.

    >
    > I'm not sure I understand the "may" part. Aren't we already using 64
    > bit time_t natively on amd64? Or maybe you're talking about 32 bit
    > compat on amd64.


    Yes, we are, and as newer server-class machines (at least) are predominantly
    64-bit, for at least the server-class market it would seem that boxes will
    probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of
    rototilling to support 64-bit time_t on i386.

    --
    John Baldwin
    _______________________________________________
    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"


  10. Re: 64 bit time_t

    John Baldwin wrote at 13:21 -0400 on Sep 17, 2008:
    > On Wednesday 17 September 2008 11:38:38 am John Hein wrote:
    > > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008:
    > > > And with amd64/x86-64, it may prove to not really be necessary.

    > >
    > > I'm not sure I understand the "may" part. Aren't we already using 64
    > > bit time_t natively on amd64? Or maybe you're talking about 32 bit
    > > compat on amd64.

    >
    > Yes, we are, and as newer server-class machines (at least) are predominantly
    > 64-bit, for at least the server-class market it would seem that boxes will
    > probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of
    > rototilling to support 64-bit time_t on i386.


    Right. I'm more concerned with planning now for y2038 on 32-bit
    embedded boxes that may still be around in 30 years. In this case, I
    think it's easy enough for me to just change my local FreeBSD tree to
    have time_t be 64 bit and recompile.

    But that doesn't help those users desperately clinging to their
    7.1-RELEASE i386 boxes 30 years from now
    _______________________________________________
    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"


  11. Re: 64 bit time_t

    On Wed, 17 Sep 2008 13:54:28 -0600, John Hein wrote:
    > But that doesn't help those users desperately clinging to their
    > 7.1-RELEASE i386 boxes 30 years from now


    If they are still running 7.1-RELEASE 30 years from now, they can give
    us their root password now and avoid the wait, I think

    /me ducks and runs
    _______________________________________________
    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"


  12. Re: 64 bit time_t

    In message: <18641.24692.875414.533794@gromit.timing.com>
    John Hein writes:
    : John Baldwin wrote at 13:21 -0400 on Sep 17, 2008:
    : > On Wednesday 17 September 2008 11:38:38 am John Hein wrote:
    : > > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008:
    : > > > And with amd64/x86-64, it may prove to not really be necessary.
    : > >
    : > > I'm not sure I understand the "may" part. Aren't we already using 64
    : > > bit time_t natively on amd64? Or maybe you're talking about 32 bit
    : > > compat on amd64.
    : >
    : > Yes, we are, and as newer server-class machines (at least) are predominantly
    : > 64-bit, for at least the server-class market it would seem that boxes will
    : > probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of
    : > rototilling to support 64-bit time_t on i386.
    :
    : Right. I'm more concerned with planning now for y2038 on 32-bit
    : embedded boxes that may still be around in 30 years. In this case, I
    : think it's easy enough for me to just change my local FreeBSD tree to
    : have time_t be 64 bit and recompile.
    :
    : But that doesn't help those users desperately clinging to their
    : 7.1-RELEASE i386 boxes 30 years from now

    It won't be on FreeBSD/arm embedded boxes :-)

    When we changed from 32-bit to 64-bit on arm, it wasn't a huge deal.
    If you don't care about ABI compatibility, then it is a simple matter
    of changing the definition of __time_t in sys/i386/include/_types.h
    and rebuilding. After all, there's no binaries not built as part of
    the controlled build process that you use in certain embedded boxes
    that I think you might be talking about ;-0.

    All that system call and ioctl and structure compat stuff is
    interesting, but just not relevant to your problem domain...

    Warner
    _______________________________________________
    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"


+ Reply to Thread