This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: utmp (was: [RFC PATCH] AARCH64/ILP32: introduce kernel time types)

On Tuesday, June 28, 2016 11:08:53 PM CEST Albert ARIBAUD wrote:
> OK, so, to sum up on utmp.
> This is what we want:
> - the utmp file structure should not depend on architecture word size
>   or, ideally, endianness.
> - the utmp/utmpx APIs should be conforming to POSIX.
> - the utmp[x] struct should not depend on kernel types.
> Here is a possible solution:
> 1. Create a separate utmp structure for the utmp file.
> 2. Make the file utmp struct's ut_tv.tv_sec field a signed 64-bit int
>    unconditionally, and ideally, its endianness should be constant.
> 3. The API utmp[x] struct's ut_tv field would be a struct timeval as
>    expected by POSIX.
> 4. GLIBC would translate between API utmp[x] structs and file utmp
>    struct, both endianness and size. When translating a 64-bit tv_sec
>    into a 32-bit tv_sec, if the value would overflow, then errno would
>    be set to EOVERFLOW and a failure value would be returned.
> 5. Upgrade path for a 'new' glibc where the 'old' and 'new' utmp file
>    formats are different in size, endianness or both: this would be best
>    handled by the packaging system, all the more since there may also be
>    dependency constraints involving some utilities which depend on the
>    utmp file structure, like utmpdump.

Nothing wrong with this approach, just another idea from how we handle
upgrading on-disk structures elsewhere:

In ext4, we use the two upper bits of the 32-bit nanoseconds to
extend the seconds. This way a structure that stores signed
seconds as 32 bit and can normally represent the range between 1902
and 2038 gets extended by another 3*136 years, so we can go until
2446 with a backwards-compatible extension. If we treat the on-disk
seconds as unsigned (we know that pre-1970 times are all guaranteed
to be invalid for utmp), we get another 68 years.

Obviously this is a trick that only works when you have full control
over all code that reads or writes the timestamps, and it doesn't
solve the endianess problem, but it avoids introducing an incompatible
format. Also, there is no reason for new architectures to do that,
they should just do what you describe above.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]