Yo Greg! On Fri, 13 Jan 2023 19:46:15 -0500 Greg Troxel <g...@lexort.com> wrote:
> "Gary E. Miller" <g...@rellim.com> 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 still work. I > >> think Solaris does this too. > > > > For some definition of "version". There is one set of syscalls for > > 32-bit time, including time in file system metadata. And another > > for 64 bit time. And only since late 2021. > > > >> I don't really follow "compile time option". The size of time_t is > >> part of the kernel ABI. > > > > Yes. BOTH sizes of time_t are part of the 32-bit linux kernel ABI. > > > > Wow. So people have to, specially for Linux, version all interfaces > that use time_t. That's not just gpsd, but all sorts of things. > > >> Or does the kernel use sys/types.h? > > > > Not relevant. > > But it has codepoints for syscalls with each flavor. > > >> The headers in sys are semantically part of the kernel, regardless > >> of how they are sliced up in packaging/maintenance. > > > > Sort of. sys/tyoes.h is part of musl or glibc. > > Yes, but it has to match the kernel. That's why I said semantically > part of. > > >> shmTime is simply using time_t, so it inherits the definition of > >> time_t from the compilation environment. POSIX says that > >> <sys/time.h> is required to define time_t: > >> > >> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html > >> > > > > Yes. And it does. Selected by D_TIME_BITS 64 > > 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 existing syscall that uses 32-bit time_t now has a 64_bit twin. So old and new binaries just work. I'm not gonna defend, that is what glibc and Linus negotitated. > What happens if a library defines D_TIME_BITS 64 and makes syscalls, > and a program which is unaware of this defines 32 and also makes > sycalls? Or is the syscall switch per .o because the names are > #defined? That can never happen. > >> > 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? > >> > >> It builds against the installed headers and just uses time_t. > > > > Yes, but which one? The 32-bit one, or the 64-bit one? > > I see. Well, I see several sane paths: > > Make a new api in json to work around the Linux approach. Only use > it on Linux, with it just serializing the struct. I really don't > like this. We will need a new API for chronyd. For now, I'm trying to save existing binaries. When we get a new chinryd API, I'd like gpsd, ntpd and chonryd to support it, but that only works going forward, which will take close to a decade to all migrate. I need a solution this week. My shmTime change gets there right away. At least for ntpshmmon, ntpd, etc. > The entire time community agrees that code will be built 64 if > that's supported on the build system. Yeah, and how to get there, while being back compatible with binaries. My shmTime idead does that. This week. > But then the "linux is one > ABI" is falling apart and it's going to be a mess as there will be > old code. No. You misunderstand the Linux ABI. Nothing is falling apart. Execpt the gpsd to chronyd interace. > So you have a rule that gpsd/ntpd/chronyd need to all be > new or all be old. And now you know why people hate *BSD. Liniux does not have "flag days" that piss everyone off. > On Linux, redefine the struct to be int64_t instead of time_t. add > options to gpsd/ntpd/chrony to move to the new way. After a bit > take out the option and int64_t is the answer. After time_t is > int64_t on all linux systems rename it back to time_t. And break back compatibility. Only as a last resort. Nad last resort is not required. > I think the third option is the way to go. That way each program can > use 32/64 as it is available but start using the new ABI now. It will > interop and as each program is built for 64 it becomes 2038-safe. Richard liked my idea, you did not discuss it. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin
pgpPJFeq0xfcu.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
