From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Alistair Francis <alistair.francis@wdc.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH 3/5] login: Add 64-bit time support
Date: Thu, 30 Jul 2020 09:34:02 -0300 [thread overview]
Message-ID: <47eaf2e2-5912-bb69-6489-6215213add58@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2007292109550.31943@digraph.polyomino.org.uk>
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.
next prev parent reply other threads:[~2020-07-30 12:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 20:51 [PATCH 1/5] login: Consolidate utmp and utmpx headers Adhemerval Zanella via Libc-alpha
2020-07-29 20:51 ` [PATCH 2/5] login: Move gnu utmpx to default implementaion Adhemerval Zanella via Libc-alpha
2020-10-22 8:15 ` Lukasz Majewski
2020-10-22 9:16 ` Andreas Schwab
2020-07-29 20:51 ` [PATCH 3/5] login: Add 64-bit time support Adhemerval Zanella via Libc-alpha
2020-07-29 21:17 ` Joseph Myers
2020-07-30 12:34 ` Adhemerval Zanella via Libc-alpha [this message]
2020-08-02 19:02 ` Maciej W. Rozycki via Libc-alpha
2020-08-02 22:05 ` Adhemerval Zanella via Libc-alpha
2020-10-22 9:16 ` Lukasz Majewski
2020-07-29 20:51 ` [PATCH 4/5] login: User 64-bit time on struct lastlog Adhemerval Zanella via Libc-alpha
2020-07-29 21:04 ` Andreas Schwab
2020-07-29 21:14 ` Andreas Schwab
2020-07-30 12:39 ` Adhemerval Zanella via Libc-alpha
2020-07-30 16:19 ` Florian Weimer via Libc-alpha
2020-07-30 18:54 ` Joseph Myers
2020-07-30 21:53 ` Adhemerval Zanella via Libc-alpha
2020-07-31 0:31 ` Joseph Myers
2020-07-30 21:46 ` Adhemerval Zanella via Libc-alpha
2020-10-22 9:25 ` Lukasz Majewski
2020-07-29 20:51 ` [PATCH 5/5] Remove __WORDSIZE_TIME64_COMPAT32 Adhemerval Zanella via Libc-alpha
2020-10-22 9:31 ` Lukasz Majewski
2020-07-29 21:08 ` [PATCH 1/5] login: Consolidate utmp and utmpx headers Joseph Myers
2020-07-30 12:36 ` Adhemerval Zanella via Libc-alpha
2020-10-22 8:06 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47eaf2e2-5912-bb69-6489-6215213add58@linaro.org \
--to=libc-alpha@sourceware.org \
--cc=adhemerval.zanella@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=joseph@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).