[Pkg-xen-devel] Bug#1063270: The "64bits time_t transition" in Debian/Xen
Andrew Cooper
andrew.cooper3 at citrix.com
Mon Feb 12 17:43:26 GMT 2024
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
More information about the Pkg-xen-devel
mailing list