Yo Greg!
On Sun, 15 Jan 2023 09:42:06 -0500
Greg Troxel wrote:
> > You can always build bad .o. But good practice is to build all .o
> > in a program or binary with the same setting. Otherwise a huge
> > number of ways to fail. That is why all gpsd c files start with:
> >
> > #include "../inc
Yo Greg!
On Sat, 14 Jan 2023 09:00:58 -0500
Greg Troxel wrote:
> "Gary E. Miller" writes:
>
> >> > 1: 64-bit time_t with 64-bit ints:
> >> > All known 64-bit distros (?)
> >> > Works after 2038
> >> > No change required.
> >>
> >> Do you mean "int64_t"?
> >
> > No, I m
Yo Greg!
On Sat, 14 Jan 2023 09:26:45 -0500
Greg Troxel wrote:
> >> Do the same thing that BSDs did: change time_t to in64_t and
> >> change the syscall codepoints. (Except you have to define
> >> something.)
> >
> > No, not change time_t. Add an incompatible alias to time_t.
>
> When y
Yo Greg!
On Sat, 14 Jan 2023 09:32:03 -0500
Greg Troxel wrote:
> "Gary E. Miller" writes:
>
> >> Which magically changes references to syscalls that use time_t, in
> >> the entire binary, to the new ones?
> >
> > Uh, once again, no. No "versioning". No syscalls are changed.
> >
> > Every e
Yo Hal!
On Sat, 14 Jan 2023 08:30:08 -0800
Hal Murray wrote:
> Does this problem go away (for another 68 years) if on 32 bit systems,
>we change the time_t in SHM to uint32_t?
No. Some ILP32 already moved to int64_t for time_t. Like all the BSDs.
> The SHM layout stays the same so all co
Does this problem go away (for another 68 years) if on 32 bit systems,
we change the time_t in SHM to uint32_t?
The SHM layout stays the same so all combinations of old/new will continue to
work today.
When the top bit turns on in 2038, recent builds will fill with 0s rather than
sign exte
Greg via Gary said:
> Does Linux version syscalls? In NetBSD, we change the codepoints when the
> ABI changes, and there is kernel code to implement the old codepoint (but no
> header support) so old binaries still work. I think Solaris does this too.
They do something like that. I'm not fam
Yo Greg!
On Fri, 13 Jan 2023 19:46:15 -0500
Greg Troxel wrote:
> "Gary E. Miller" writes:
>
> >> Does Linux version syscalls? In NetBSD, we change the codepoints
> >> when the ABI changes, and there is kernel code to implement the old
> >> codepoint (but no header support) so old binaries sti
Yo Richard!
On Fri, 13 Jan 2023 19:08:10 -0600
Richard Laager via devel wrote:
> > So, looking only at option 4. The one that we can improve.
>
> I think you have captured the options correctly.
Plus the corrections from Greg.
> > That maintains compatibility with existing SHM users.
> > T
Yo Greg!
On Fri, 13 Jan 2023 20:20:48 -0500
Greg Troxel wrote:
> Greg Troxel writes:
>
> I just had a realization. What Linux is doing is more or less:
>
> Do the same thing that BSDs did: change time_t to in64_t and change
> the syscall codepoints. (Except you have to define something
Yo Greg!
On Fri, 13 Jan 2023 19:55:47 -0500
Greg Troxel wrote:
Sorry, you correctly point out I was sloppy and mistakes in
nomenclature.
See below for more.
> "Gary E. Miller" writes:
>
> > 1: 64-bit time_t with 64-bit ints:
> > All known 64-bit distros (?)
> > Works after 2038
>
On 1/13/23 18:33, Gary E. Miller via devel wrote:
Yo All!
Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
Yo Greg!
On Fri, 13 Jan 2023 19:33:35 -0500
Greg Troxel wrote:
> [dropping ntpsec because they bounced my mail]
>
> "Gary E. Miller" writes:
>
> >> but int is ok in
> >> practice, on ILP32. On IP16L32, it's not, but we aren't building
> >> for PDP-11 any more :-)
> >
> > What is ILP32?
Yo All!
Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
Works after 2038
No change required.
3: 32-bi
Yo Hal!
On Fri, 13 Jan 2023 13:50:23 -0800
Hal Murray wrote:
> I'm missing the big picture. I've been assuming that gpsd and ntpsec
> and everybody else will use time_t from the system header files.
> (without tweaking anything)
A valid assumption, until now. glibc on 32-bit, now tells us wwe
Yo James!
On Fri, 13 Jan 2023 13:43:38 -0800 (PST)
James Browning wrote:
> > On 01/13/2023 1:06 PM PST Hal Murray wrote:
> >
> >
> > If we make any changes to SHM, we should switch to a setup where
> > the memory is read only. The idea is to allow multiple readers.
> >
> > The trick to imple
g...@rellim.com said:
> Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit time_t on
> 32-bit Linux without much work.
> But...
> How to get that 2038 compatible time to ntpd and chronyd? That is a much
> bigger problem.
> This is a problem for glibc on 32 bits. And int is 32
> On 01/13/2023 1:06 PM PST Hal Murray wrote:
>
>
> If we make any changes to SHM, we should switch to a setup where the memory is
> read only. The idea is to allow multiple readers.
>
> The trick to implementing that is to have 2 counters.
> X and Y are initialized to the same value.
> The wri
Yo Hal!
On Thu, 12 Jan 2023 23:15:25 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
> > time_t on 32-bit Linux without much work.
>
> What does "without much work" mean?
See commit 19d76e95312b03028752d57e76098d56adac63d
Yo Hal!
On Fri, 13 Jan 2023 13:06:28 -0800
Hal Murray wrote:
> If we make any changes to SHM, we should switch to a setup where the
> memory is read only. The idea is to allow multiple readers.
And how do we do that? Without mutexes or atomics? The "new normal"
is to avoid those because they
Yo Greg!
On Fri, 13 Jan 2023 07:11:49 -0500
Greg Troxel wrote:
> "Gary E. Miller" writes:
>
> > Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
> > time_t on 32-bit Linux without much work.
>
> Interesting to hear; I had assumed time_t on Linux was changed long
> ago to in
If we make any changes to SHM, we should switch to a setup where the memory is
read only. The idea is to allow multiple readers.
The trick to implementing that is to have 2 counters.
X and Y are initialized to the same value.
The writer bumps X, updates the data, then bumps Y.
The reader
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
Begin forwarded message:
Date: Fri, 13 Jan 2023 07:11:49 -0500
From: Greg Troxel
To: "Gary E. Miller"
Cc: gpsd dev ,
Subject: Re: ✘64-bit time_
Yo James!
On Fri, 13 Jan 2023 08:49:34 -0800 (PST)
James Browning wrote:
> > This makes my head hurt...
>
> IIRC there are a few users of those interfaces; linuxptp, gpsd,
> classic NTP, NTPsec, and chrony.
Multiplied by the number of distros that carry each, and update on their
own schedul
Yo Richard!
On Fri, 13 Jan 2023 13:43:06 -0600
Richard Laager wrote:
> On 1/12/23 19:10, Gary E. Miller via devel wrote:
> > How does ntpd know what size time_t to use? And thus know the size
> > of shmTime? How do we know portably, preserving backwards and
> > forwards compatibility?
> >
> >
On 1/12/23 19:10, Gary E. Miller via devel wrote:
How does ntpd know what size time_t to use? And thus know the size of
shmTime? How do we know portably, preserving backwards and forwards
compatibility?
In hindsight, maybe shmTime should have started with a 1 char version
field,or magic field.
> On 01/12/2023 5:10 PM PST Gary E. Miller wrote:
>
>
> Yo All!
>
> Cross-posted to gpsd-dev and devel@ntpsec.org
>
> Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
> time_t on 32-bit Linux without much work.
>
> But...
>
> How to get that 2038 compatible time to ntpd and
Yo All!
Cross-posted to gpsd-dev and devel@ntpsec.org
Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
time_t on 32-bit Linux without much work.
But...
How to get that 2038 compatible time to ntpd and chronyd? That is a
much bigger problem.
Extracted from include/ntpshm.h:
s
28 matches
Mail list logo
