All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: distributions@lists.linux.dev, Thorsten Kukuk <kukuk@suse.com>
Cc: Eric Blake <eblake@redhat.com>
Subject: Re: Y2038, glibc and utmp/utmpx on 64bit architectures
Date: Fri, 03 Mar 2023 23:11:49 +0100	[thread overview]
Message-ID: <2900303.CPfdCl3LZh@nimes> (raw)
In-Reply-To: <20230303205500.GA13773@suse.com>

Thorsten Kukuk wrote:
> > Do the glibc developers plan to remove the utmpx
> > interface as well (together with utmp interface)?
> 
> In glibc, utmpx is just an alias for utmp.
> 
> > If yes, then
> >   - What is the point of your suggestion to "use the utmpx and not utmp
> >     interface", above?
> 
> utmps only supports the utmpx interface, not utmp. So if you want to use
> utmps, you need to convert all source code to utmpx.

Thanks for the explanations. It's clear now.

> >   - Since there is no "FUTURE DIRECTIONS" in POSIX
> >     https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/endutxent.html
> >     will the utmpx interface get deprecated in POSIX, or stay as it is?
> >     Is the Austin Group already involved?
> 
> Linux is not POSIX conform, never was and there was never the plan to
> become, but it tries to be as compatible with POSIX as possible where
> it makes sense. If it does not make sense, POSIX will not be used. You
> should be able to find several examples in glibc, where interfaces
> derivate slightly from POSIX because the POSIX interface didn't made any
> sense.
> Parts of POSIX are really old (don't know how old utmp/utmpx are, but
> they did exist already since a long time before I started to work
> with Unix, and that's really a long time ago) and things are changing.
> Today, utmp/utmpx create more problems then it solve. Many features of
> it where never used on Linux or are meanwhile no longer used, at least
> not with systemd.
> There is just no benefit from it anymore. ...

I don't disagree with that.

Just that, as part of keeping Linux + glibc as close a possible to POSIX
over the long term, when we remove a feature from glibc that is POSIX-
standardized, we should also remove (or at least mark as LEGACY) this
part from POSIX. POSIX evolves, partially based on our inputs. I don't see
the deprecation of [1][2] on the Austin Group's agenda so far [3].

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/utmpx.h.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/endutxent.html
[3] https://www.austingroupbugs.net/view_all_bug_page.php




      reply	other threads:[~2023-03-03 22:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 10:46 Y2038, glibc and utmp/utmpx on 64bit architectures Thorsten Kukuk
2023-03-03 16:51 ` A. Wilcox
     [not found] ` <3067bd0ec5134b039cdb8be9db8da8e5@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 17:07   ` Thorsten Kukuk
2023-03-03 20:09     ` Anna
2023-03-03 20:25     ` Bruno Haible
     [not found]     ` <c420abff6abd43cabac8c2fa5d812091@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 20:55       ` Thorsten Kukuk
2023-03-03 22:11         ` Bruno Haible [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2900303.CPfdCl3LZh@nimes \
    --to=bruno@clisp.org \
    --cc=distributions@lists.linux.dev \
    --cc=eblake@redhat.com \
    --cc=kukuk@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.