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 Mon, Sep 30, 2002 at 01:43:26PM -0700, Roland McGrath wrote:
> > Now an important question is whether we want to do something similar
> > on x86-64, s390/s390x and sparc/sparc64.
> > Because when both 32-bit and 64-bit programs will use utmp/utmpx,
> > the files will contain garbage.
> 
> Well, I'd been presuming the formats had been settled for those
> architectures already.  If it's acceptable or desireable to change them,
> then let's look at all the architectures at once.  If we can just change
> the one sysdeps/gnu/bits/utmp{x,}.h file to use bits/wordsize.h and be
> consistent everywhere, that would be much better than lots of new utmp.h files.

That we certainly can't. We have to keep it for Alpha and IA-64 for sure.
I think we can not-too-painfully change it for sparc64.
Dunno about x86-64 and s390x.

I admit I haven't looked at utmp handling much.
The primary question is whether there are any applications which
access /var/log/wtmp, /var/log/lastlog etc. directly.
If not, we could as well keep the current structures on the bi-arch arches,
say use the 32-bit file format with the high tv_sec bits in some
unused field and write libc internal accessors.
If yes, things are more interesting...

> But for existing platforms with a wide struct timeval, this would break the
> existing 64-bit utmp files, and would need versioning on all the interfaces
> using struct utmp if we don't want to break the ABIs too.

	Jakub


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