This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ppc64 utmp changes


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.

I think in bits/wordsize.h would be best.

> #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?

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?

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]