System call conversion for year 2038

Re:System call conversion for year 2038 by ghshephard on Wednesday May 13, 2015 @09:43AM (#9538842)

OpenBSD made some good progress back in 5.5 (May, 2014)

http://www.openbsd.org/55.html

  o time_t is now 64 bits on all platforms.
  o From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready
  o The entire source tree (kernel, libraries, and userland 
    programs) has been carefully 
    and comprehensively audited to support 64-bit time_t.
  o Userland programs that were changed include arp(8),
    bgpd(8), calendar(8), cron(8), find(1), 
    fsck_ffs(8), ifconfig(8), ksh(1), ld(1), ld.so(1),
    netstat(1), pfctl(8), ping(8), rtadvd(8), ssh(1),
    tar(1), tmux(1), top(1), and many others, including
    games!
  o Removed time_t from network, on-disk, and database 
    formats.
  o Removed as many (time_t) casts as possible.
  o Format strings were converted to use %lld and (long
    long) casts.
  o Uses of timeval were converted to timespec where 
     possible.
  o Parts of the system that could not use 64-bit 
     time_t were converted to use unsigned 32-bit instead,
     so they are good till the year 2106.
  o Numerous ports throughout the ports tree received 
    time_t fixes.

[ Parent | on HN ]

Re:System call conversion for year 2038 by justincormack on Wednesday May 13, 2015 @09:54AM (#9538903)

NetBSD also switched over in 6.0 back in 2012.

[ Parent | on HN ]

Re:System call conversion for year 2038 by ivoras on Wednesday May 13, 2015 @10:04AM (#9538978)

And FreeBSD apparently started in 2001: http://mm.icann.org/pipermail/tz/2004-June/012487.html

While it did advance the state of the art in many things, Linux really clings to reinventing the wheel in obvious cases. NIH FTW.

[ Parent | on HN ]

Re:System call conversion for year 2038 by abadabalinux4u on Wednesday May 13, 2015 @10:58AM (#9539379)

While Linux certainly reinvents the wheel in some cases and NIHism exists everywhere, the syscall interface of an operating system is not the place where one can just lift BSD code and drop it in and expect it to work. This work needs to be done carefully in a Linux-specific way. The "NIH" approach is sort of a requirement.

[ Parent | on HN ]

Re:System call conversion for year 2038 by duaneb on Wednesday May 13, 2015 @01:14PM (#9540436)

Linux seems to have a policy of avoiding breaking changes. Nice for maintaining software, but it's not the best quality kernel as a result.

[ Parent | on HN ]

Re:System call conversion for year 2038 by the_why_of_y on Thursday May 14, 2015 @02:06PM (#9546580)

There is a big difference: the *BSD systems have a tightly integrated base system, where kernel and libc are adapted to changes in lockstep, and there is no stable kernel ABI.

FreeBSD ABI stability is not guaranteed between major releases (only between minor releases), while OpenBSD does not even guarantee ABI stability between minor releases.

Linux and GNU libc are separate projects, and there are pretty strong compatibility guarantees for the Linux syscall ABI; the glibc ABI is also stable, and glibc uses ELF symbol versioning to provide older deprecated functions for compatibility.

This means the system is more modular, but at the cost that interface changes like changing 32-bit time_t to 64-bit require a lot more effort and coordination.

Of course the advantage of the Linux approach is that existing application binaries will continue to run, even ones that do syscalls directly or with statically linked libc.

----

Edited to add: actually it turns out you were wrong with your claim about 64-bit time_t in FreeBSD:

Here is the current trunk header where it defines a 32-bit time_t for the i386 architecture.

https://svnweb.freebsd.org/base/head/sys/x86/include/_types....

[ Parent | on HN ]

Re:System call conversion for year 2038 by justincormack on Wednesday May 13, 2015 @10:40AM (#9539247)

That was on 64 bit systems; those all switched a long time ago, despite the author of that thread disliking it...

[ Parent | on HN ]

Re:System call conversion for year 2038 by noselasd on Wednesday May 13, 2015 @11:58AM (#9539903)

In all fairness, linux does this, on 32 bit platforms where time_t is 32 bit, to be binary backwards compatible, which is a different goal from what the BSDs do/did, which is a rip and replace approach, where you'll need to recompile applications.

[ Parent | on HN ]