lkml.org 
[lkml]   [2012]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject64-bit time on 32-bit systems
    Resuming a long-stuck discussion...

    On 08/31/2011 10:19 AM, Linus Torvalds wrote:
    > On Wed, Aug 31, 2011 at 10:09 AM, H. Peter Anvin <hpa@zytor.com> wrote:
    >>>
    >>> I suspect only sane solution to this (having thought about it some
    >>> more) is to just say "POSIX is f*^&ing wrong".
    >>
    >> Urk. Someone had the bright idea of defining tv_nsec as "long" in the
    >> standard, whereas tv_usec is suseconds_t. F**** brilliant, and more
    >> than a little bit stupid.
    >
    > I think tv_nsec was just overlooked, and people thought "it has no
    > legacy users that were 'int', so we'll just leave it at 'long', which
    > is guaranteed to be enough for nanoseconds that only needs a range of
    > 32 bits".
    >
    > In contrast, tv_usec probably *does* have legacy users that are "int".
    >
    > So POSIX almost certainly only looked backwards, and never thought
    > about users who would need to make it "long long" for compatibility
    > reasons.
    >
    > The fact that *every*other*related*field* in POSIX/SuS has a typedef
    > exactly for these kinds of reasons just shows how stupid that "long
    > tv_nsec" thing is.
    >
    > I suspect that on Linux we can just say "tv_nsec" is suseconds_t too.
    > Then we can make time_t and suseconds_t just match, and be "__s64" on
    > all new platforms.
    >

    So I somewhat accidentally stumbled onto what appears to the the reason
    for this while cleaning up posix_types.h last night.

    The problem at hand seems to be that suseconds_t is 32 bits on SPARC64.
    This appears to be the case in both Linux and Solaris, which is
    probably why struct timespec has "long" instead of suseconds_t (Sun
    always have been prominent on the POSIX committee.)

    As such, I don't think we can redefine struct timespec to have
    suseconds_t for the nanosecond field, even on Linux. We could define
    snseconds_t, or we would have to do something really ugly like define a
    padding field when on a 32-bit platform (which the kernel would then
    have to ignore when reading from userspace by truncating the 64-bit
    value rather than signaling an error if the upper 32 bits are set.)

    snseconds_t seems semi-reasonable to me... I guess we'd have to push
    that at the POSIX people. Fortunately it shouldn't break anything to
    have it be a wider type than is otherwise necessary.

    -hpa

    --
    H. Peter Anvin, Intel Open Source Technology Center
    I work for Intel. I don't speak on their behalf.



    \
     
     \ /
      Last update: 2012-02-08 22:39    [W:3.483 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site