LinuxKPI: define time64_t

[bz]

Summary

Define time64_t to time_t apart from i386 where we define it to int64_t
given the native implementation still is int32_t.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[markj]

In Linux this is defined in time64.h, but here is fine for now I guess.

[imp]

sys/compat/linuxkpi/common/include/linux/time.h

49

why not just typedef int64_t time64_t; and be done with it?

[imp]

So I don't think the ifdef is needed or desirable. Linux wants time64_t to be exactly a int64_t, so we should do that.

[bz]

sys/compat/linuxkpi/common/include/linux/time.h

49

I guess people know what the native time_t is (on i386) and can deal with it that it may never be a 64bit value. Or otherwise we hope i386 is gone by then -- at least from LinuxKPI.
It's likely only time_uptime?

I mostly did this as documentation to point out that there is a discrepancy.

I am fine either way and I'll happily update it if that's the consensus.

[imp]

So I'm good either way, I just don't like #ifdefs, especially ones that are 'logical' only and not really needed.
But I've said my piece, and will move along.

sys/compat/linuxkpi/common/include/linux/time.h

49

I'd be tempted to use the i386 line as it is now, and only that line :)

There's also an ambiguity in time_t. It's both an absolute time and a relative time (well, really, the absolute time is just a relative time to 1970). Uptime is a relative time with an epoch of when the computer was last booted. So for things like time_uptime, it will be completely adequate. The longest known Unix uptime is still much less than 66 years, and i386 lunuxkpi users are going to encounter several other issues well before that runs out, even if they booted today and depended on linux_uptime....

[bz]

plainly typedef time64_t to int64_t as suggested by @imp.

[bz]

@markj @imp are you fine with this as-is now?