This is the mail archive of the
mailing list for the glibc project.
Re: utmp (was: [RFC PATCH] AARCH64/ILP32: introduce kernel time types)
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Yury Norov <ynorov at caviumnetworks dot com>, Andreas Schwab <schwab at suse dot de>, nd at arm dot com, vapier at gentoo dot org, cmetcalf at tilera dot com, pinskia at gmail dot com, cmetcalf at mellanox dot com, bamvor dot zhangjian at huawei dot com, catalin dot marinas at arm dot com, fweimer at redhat dot com, Prasun dot Kapoor at cavium dot com, maxim dot kuvyrkov at linaro dot org
- Date: Tue, 28 Jun 2016 23:49:11 +0200
- Subject: Re: utmp (was: [RFC PATCH] AARCH64/ILP32: introduce kernel time types)
- Authentication-results: sourceware.org; auth=none
- References: <1467103498-24243-1-git-send-email-ynorov at caviumnetworks dot com> <alpine dot DEB dot 2 dot 20 dot 1606281150310 dot 3149 at digraph dot polyomino dot org dot uk> <20160628230853 dot 2f8d1473 dot albert dot aribaud at 3adev dot fr>
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.