Re: The "64bits time_t transition" in Debian/Xen

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/02/2024 5:27 pm, zithro wrote:
> Hey all,
>
> the Debian project is focused on the "2038 time_t" switch.
> So the maintainers of the Debian Xen package must ensure that all
> imported Xen code conforms to the new Debian standards.
>
> I was asked by Andrew Cooper to post here about this, I'll quote him :
> "So I had been idly wondering whether Xen would match up to Debian's new
> policy, and it appears not
> this topic really needs to be brought up on the xen-devel mailing list
> do you have any more details as to what has gone wrong?
> this is something we ought to arrange to happen in CI by default
> but it sounds like there's some work needed first"
>
> (Not answering the question because I'm just a messenger).

xen.git/xen$ git grep -w time_t -- :/
../tools/console/client/main.c:106:     time_t start, now;
../tools/console/daemon/io.c:272:       time_t now = time(NULL);
../tools/libs/light/libxl_qmp.c:116:    time_t timeout;
../tools/libs/light/libxl_qmp.c:585:                               
time_t ask_timeout)
../tools/libs/light/libxl_x86.c:516:        time_t t;
../tools/libs/toollog/xtl_logger_stdio.c:61:        time_t now = time(0);
../tools/tests/xenstore/test-xenstore.c:453:    time_t stop;
../tools/xenmon/xenbaked.c:98:time_t start_time;
../tools/xenstored/core.c:109:  time_t now;
../tools/xenstored/core.h:150:  time_t ta_start_time;
../tools/xenstored/domain.c:143:        time_t mem_last_msg;
../tools/xenstored/domain.c:188:static time_t wrl_log_last_warning; /*
0: no previous warning */
../tools/xenstored/domain.c:1584:       time_t now;
../tools/xenstored/lu.c:160:    time_t now = time(NULL);
../tools/xenstored/lu.c:185:    time_t now = time(NULL);
../tools/xenstored/lu.c:292:    time_t now = time(NULL);
../tools/xenstored/lu.h:32:     time_t started_at;
../tools/xentop/xentop.c:947:   time_t curt;
../tools/xl/xl_info.c:742:static char *current_time_to_string(time_t now)
../tools/xl/xl_info.c:759:static void print_dom0_uptime(int short_mode,
time_t now)
../tools/xl/xl_info.c:810:static void print_domU_uptime(uint32_t domuid,
int short_mode, time_t now)
../tools/xl/xl_info.c:847:    time_t now;
../tools/xl/xl_vmcontrol.c:336:        time_t start;
../tools/xl/xl_vmcontrol.c:495:    time_t now;
../tools/xl/xl_vmcontrol.c:504:    if (now == ((time_t) -1)) {
../tools/xs-clients/xenstore_control.c:33:    time_t time_start;
arch/x86/cpu/mcheck/mce.h:224:    uint64_t time;     /* wall time_t when
error was detected */
arch/x86/time.c:1129: * machines were long is 32-bit! (However, as
time_t is signed, we


I don't see any ABI problems from using a 64bit time_t.  The only header
file with a time_t is xenstored/lu.h which is a private header and not a
public ABI.

I guess we fell into the "could not be analysed via
abi-compliance-checker" case?

~Andrew