gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] ✘timestamp_t is dead. Long live timespec_t


From: Greg Troxel
Subject: Re: [gpsd-dev] ✘timestamp_t is dead. Long live timespec_t
Date: Fri, 20 Sep 2019 09:29:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
>
> On Thu, 19 Sep 2019 20:01:58 -0400
> Greg Troxel <address@hidden> wrote:
>
>> "Gary E. Miller" <address@hidden> writes:
>> 
>> > timespec_t, at least on 64 bit systems, is good for the 2038 UNIX
>> > time overflow event.  Not much we can do for 32-bit systems until
>> > the system calls get fixed.  
>> 
>> I don't really follow this, and assume it's about Linux only.  On
>> NetBSD (for the last bunch of years), time_t is int64_t, regardless
>> of CPU native word size.
>
> The only one I know that is int32_t is 32-bit Linux.  Good to know that
> NetBSD is good for 2038.

I guess it's an interesting question how many 32-bit CPUs will be
running unix-like systems in 2038, using operating systems that haven't
changed time_t.  Even now the microcrontrollers I am using are 32-bit
now.  But 2038 is starting to seem not so far away; I remember people
talking about 2020 in 2000.

But, I still don't see how timeval vs timespec is different.  Both use
time_t, which either is or isn't big enough on any particular system.

>> Presumably you are including sys/time.h, per POSIX:
>> 
>>   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html
>
> Yup.

Great

>> > timespec_t is easy to work with, as long as you use the macros in
>> > timespec.h.  A few more places in the code can be converted to use
>> > the macros.  
>> 
>> Can you point me to where POSIX defines timespec.h, and the macros?  I
>> was unable to find those.  I wonder if they are Linux only.
>
> timespec.h, and the macros, have been in gpsd for a a few revisions.  So
> little new there.  Well tested on many distros.

Sorry, I assumed you meant sys/timespec.h, rather than a timespec.h in
gpsd, and macros defined by gpsd source code.  I see gpsd/timespec.h
now.  (NetBSD has a tiny sys/timespec.h, and I assumed that this was an
accommodation for programs that used nonstandard headers on other
systems.  Now I have no idea why -- it may be to let timespec be defined
without dragging in all of sys/time.h.  But a red herring in any case.)

> The change was finally using timespec exclusively.  Flushing the
> timestamp_t from the corners.  The code changes from timestamp_t to
> timespec_t are pretty simple and obvious.

Great - that makes sense.

I ran a build on netbsd-8/amd64 and after dealing with some scons
lossage (bad cache files), got it to build ok and livetest with a ublox
8.

There seems to be some significant trouble with scons claiming the C
compiler doesn't work and writing this in the cache and then believing
that after a clean.  I haven't figured that out yet.

I am pretty sure I saw that there were no warnings from building, when I
managed to get scons to build normally.


A few nits:

I think we've talked about this, but xgps and cgpsd from 3.19 fail to
interoperate with the new gpsd, complaining about version mismatch.
Given that they could be on separate machines, and use the client
protocol, this seems wrong but I'm guessing it's a feature.

The docs are .adoc (peachy) but they refer to other docs as foo.txt.
Thanks to completion I merely noticed this.

The other thing I'm unclear on is python 2.7 vs 3.7 (or 3.x, for some x
at least 6, these days).  I have been having more and more scons issues
globally because pkgsrc can build either 2.7 or 3.7 scons, but they both
install "scons" so they conflict, and there's still a lot of stuff that
doesn't work with 3.7 (we just flipped the default to 3.7 in the
spring).  build.adoc says 2.7 or 3.7 should be fine.  These days, I want
to use 3.7 for anything where that works.  Is gpsd truly agnostic, and
is it believed that using 3.7 is 100% ok?

I don't have a binary "python" and set PYTHON=python2.7 in the
environment before calling scons.  This used to work fine, and now it
doesn't seem to (python not found) -- but lots of things seem odd which
is probably just one other issue causing multiple oddnesses.  Has
anything changed about this?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]