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: Roland McGrath <roland at redhat dot com>
- Cc: aj at suse dot de, schwidefsky at de dot ibm dot com, Steve Munroe <sjmunroe at us dot ibm dot com>, libc-alpha at sources dot redhat dot com
- Date: Tue, 1 Oct 2002 13:54:49 +0200
- Subject: Re: [PATCH] ppc64 utmp changes
- References: <20020930230034.X3451@sunsite.ms.mff.cuni.cz> <200210011044.g91AiwF21368@magilla.sf.frob.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 01, 2002 at 03:44:58AM -0700, Roland McGrath wrote:
> > That we certainly can't. We have to keep it for Alpha and IA-64 for sure.
>
> Right, the always-64 platforms. I would be happier with a new sysdeps
> macro for 64-bit platforms saying whether they have 32-bit-compatible file
> formats, just defined in some other file, and not having bits/utmp{x,}.h
> copied. It could be a macro just about utmp in an extra tiny bits/ header,
> or it could be in bits/wordsize.h something like __WORDSIZE_COMPAT32 and
> perhaps be used by other such cases if they come up. i.e.
>
> #if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
> struct { __int32_t ... }
> #else
> struct timeval ...;
> #endif
>
> > I think we can not-too-painfully change it for sparc64.
> > Dunno about x86-64 and s390x.
>
> It's sounding like everyone is saying that breaking the existing 64-bit
> file formats for all these platforms is ok. Either people just don't care,
> or those file formats have never really been used by 64-bit programs. If
> either of those is so, does that mean that noone cares about or ever used
> the various struct utmp-using ABIs either? Can we really change these ABIs
> (the size and layout of struct utmp) without versioning?
Unfortunately, it seems like there are tons of programs mucking directly
with these files (brief skim of my /usr/bin directory revealed already 28
of them).
IMHO they should be converted eventually, but that won't happen immediately.
Jakub