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

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Bonjour Joseph,

Le Tue, 28 Jun 2016 11:55:29 +0000, Joseph Myers
<joseph@codesourcery.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.

Cordialement,
Albert ARIBAUD
3ADEV