This is the mail archive of the
mailing list for the glibc project.
utmp (was: [RFC PATCH] AARCH64/ILP32: introduce kernel time types)
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: 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>, <libc-alpha at sourceware dot org>, <arnd at arndb dot de>, <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:08:53 +0200
- Subject: 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> <mvmshvxk4n6 dot fsf at hawking dot suse dot de> <20160628102000 dot GA24779 at yury-N73SV> <mvmk2h9k3qh dot fsf at hawking dot suse dot de> <20160628104105 dot GD24025 at yury-N73SV> <57725DE8 dot 80708 at arm dot com> <alpine dot DEB dot 2 dot 20 dot 1606281150310 dot 3149 at digraph dot polyomino dot org dot uk>
Le Tue, 28 Jun 2016 11:55:29 +0000, Joseph Myers
<email@example.com> a Ãcrit :
> On Tue, 28 Jun 2016, Szabolcs Nagy wrote:
> > i agree with andreas.
> > i don't think kernel names should be involved here.
> I also agree. The types in utmp have *nothing* to do with the kernel.
> Kernel time types should not appear in any public glibc interfaces at all,
> only in code translating between kernel and glibc interfaces.
> > (ideally the on-disk format would be the same on all
> > abis not just on the ilp32 and lp64 abi of the same arch,
> > since the same rootfs may be mounted on different hosts
> > with a proper multiarch setup.. and ideally the public
> > struct types would not need any changes to make this work,
> > they could be serialized into a portable format.)
> Yes (subject to a question of whether we actually care about
> endianness-independence of the on-disk format, or only about such cases as
> AArch32 / AArch64 ILP32 / AArch64 LP64 all of same endianness). I think
> the goal should be that the struct types in the headers are
> POSIX-conforming on all architectures, with translation for file input /
> output as needed so that applications with 32-bit and 64-bit time_t, and
> applications for different ABI variants, can access the same files, those
> files always storing 64-bit time values. So if any changes to utmp
> structures are being made, let's make them in that direction.
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.