[PATCH 3/5] login: Add 64-bit time support

[Adhemerval Zanella]

On 29/07/2020 18:17, Joseph Myers wrote:
> On Wed, 29 Jul 2020, Adhemerval Zanella via Libc-alpha wrote:
> 
>> New symbols for getutent, getutent_r, getutid, getutid_r, getutline,
>> getutline_r, getutmp, getutmpx, getutxent, getutxid. getutxline,
>> pututline, pututxline, updwtmp, updwtmpx, and login are added to
>> all architecture but s390-32 (which already added 64-bit time support
>> on 32-bit ABI on glibc 2.9).
> 
> I thought those structures appeared in external files (/var/run/utmp, 
> /var/log/wtmp, /var/log/lastlog), which means changing them is problematic 
> even with symbol versioning.  Do the files keep their existing formats 
> with the new versions of the functions translating to and from the 64-bit 
> format when reading / writing those files?  Do they get new formats with 
> the old versions of the functions instead being the ones that translate 
> (if so, what is the process distributions are expected to use to convert 
> existing files on upgrade / enable old wtmp files in the old format to 
> continue to be read by new code)?  I think a detailed description of the 
> overall strategy for maintaining compatibility with existing data in files 
> is needed, both in the patch / patch series description and in the NEWS 
> file describing anything required to be done on upgrade to avoid losing or 
> corrupting data.
> 

The strategy I used was the same done by s390-32 some time ago, where
the var/run/utmp, /var/log/wtmp, /var/log/lastlog would use the new
64-bit time regardless and the 32-bit compat symbols convert the 32-bit
entries to the internal 64-bit ones.  Afaik there is not conversion tool 
to handle that, so the system administration was supposed to reset such 
files in a glibc upgrade.

I thought about the underlying issuesand another strategy I considered
was to use new register types for 64-bit time symbols (by mapping the 
RUN_LVL, etc. to internal types). The 32-bit time compat symbols would then
write the entries as-is.  

There are some issues with this approach: how compat symbols would handle 
64-bit time entries? Would them be just ignored (as the current semantic 
for other 64-bit symbols which return EOVERFLOW) or the entry would be 
converted and the time clamped (and thus returning potentially 
invalid/misleading time results)?

Another issue is extra code complexity, it requires routines to convert
to 64-bit entries from 32-bit entries and the 32-bit compat symbols won't
be based on exported ABI (which requires to add extra testing to handle
the iteration between 64-bit and 32-bit entries).

I am not sure if this extra complexity to handle multiple registers
types does days off (and I don't know how was s390-32 transition), but
if this is indeed a desirable feature I think I can spend some time to
sort this out.