This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] ppc64 utmp changes
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Schwidefsky <schwidefsky at de dot ibm dot com>
- Cc: Roland McGrath <roland at redhat dot com>, aj at suse dot de, Steve Munroe <sjmunroe at us dot ibm dot com>, bcollins at debian dot org, libc-alpha at sources dot redhat dot com
- Date: Tue, 1 Oct 2002 16:55:46 +0200
- Subject: Re: [PATCH] ppc64 utmp changes
- References: <OF661DDA68.9402585C-ONC1256C45.firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 01, 2002 at 03:05:30PM +0200, Martin Schwidefsky wrote:
> > For sparc64 it can be changed without versioning, Ben, do you agree?
> > For x86-64, as Andreas said, I believe everybody can recompile glibc
> > and recompile those few programs which access wtmp etc. files directly
> > (SysVinit, anything else?) and > /var/log/wtmp.
> > ppc64 initiated this, so is ok with this change too.
> > The only question is s390x, Martin?
> Hmm, I checked utmp.h and utmpx.h on a 31 bit system 64 bit system. The
> files are identical but the structures have a different layout (__time_t
> and __suseconds_t have type unsigned long -> 4 vs. 8 byte). This makes
> the /var/log/wtmp format different on 31bit vs. 64bit. So 31 bit programs
> running on 64 bit may not access /var/log/wtmp. To make things worse we
> already have a 64 bit distro out there so we can't simply change utmp.h.
> Now it depends which programs do access /var/log/wtmp. For the standard
> stuff in a distribution we always use the 64 bit versions of the programs.
I was afraid of that :(.
Below is a partial list of packages on my box which probably do direct wtmp access
on my box:
Given the size of this list, I'm afraid the chance of third party packages
doing wtmp access is extremely high.