This is the mail archive of the
libc-alpha@sources.redhat.com
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>, Ulrich Drepper <drepper at redhat dot com>, Andreas Jaeger <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: Wed, 2 Oct 2002 17:10:25 +0200
- Subject: Re: [PATCH] ppc64 utmp changes
- References: <OF16F4D77D.FB59D986-ONC1256C46.0047B8D3@de.ibm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Oct 02, 2002 at 04:47:55PM +0200, Martin Schwidefsky wrote:
>
> > I haven't changed s390x, but IMHO it is better to recompile the affected
> > apps now in the /usr/lib -> /usr/lib64 transition which changes most
> > of the things anyway, than to suffer forever.
>
> I came to the conclusion that s390x will need the __WORDSIZE_COMPAT32
> version
> of utmp.h/utmpx.h as well. Fact is there are userland programs that access
Ok.
> /var/log/wtmp directly. To get this kind of program going under the 31 bit
> emulation the system /var/log/wtmp file needs to have the same format for
> 31 bit and 64 bit. Period.
> This leaves the question about "old" 64 bit programs that rely on the
> existing
> format of /var/log/wtmp. Apps that directly access /var/log/wtmp with the
> existing format can't be helped if we want to achive coexistence (the old
> question about how you want to die...). Apps that use the glibc to get/pass
> information from/to wtmp could be helped with versioning. Now the question:
> are there any functions other then getutent, getutid, getutline, pututline,
> getutxent, getutxid, getutxline, pututxline and login that get/pass a
> structure
> from utmp.h or utmpx.h?
login, updwtmp, getutent, getutid, getutline, pututline, getutent_r,
getutid_r, getutline_r, getutxent, getutxid, getutxline, pututxline,
updwtmpx, getutmp, getutmpx
at least.
Jakub