This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: make existing mips files multi-ABI
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: libc-alpha at sources dot redhat dot com
- Date: 04 Apr 2003 04:55:18 -0300
- Subject: Re: make existing mips files multi-ABI
- Organization: GCC Team, Red Hat
- References: <orof4eb7xj.fsf@free.redhat.lsd.ic.unicamp.br><u8llzi45t5.fsf@gromit.moeb><or1y0wdur2.fsf@free.redhat.lsd.ic.unicamp.br><u8adfkf1cv.fsf@gromit.moeb><orwuioasd8.fsf@free.redhat.lsd.ic.unicamp.br><ord6k348tl.fsf@free.redhat.lsd.ic.unicamp.br><oradf6zp9z.fsf@free.redhat.lsd.ic.unicamp.br><u8fzoyaern.fsf@gromit.moeb>
On Apr 4, 2003, Andreas Jaeger <aj at suse dot de> wrote:
> Please make the userland have space for a 64-bit time_t type and
> convince the kernel developers to do the same.
They do, kind of. There's padding that would make room for it, but
it's unused, and it certainly wouldn't work in both endiannesses.
Anyway, the kernel won't be changing these data structures because
they're the same data structures used by o32 (stat and stat64). The
only point open for debate is whether n32 is going to use only the
syscall compatible with o32's stat64 or both newstat and stat64. n64
has only the (equivalent of the) o32 stat64 system call.
> Use the kernel only if it supports (or has space to support)
> everything we think of ;-) (space for 64-bit dev_t, 64-bit time_t
> etc),
Given the constraints above, I suppose I should give up on the idea of
avoiding the conversion functions. Oh, well, that's too bad.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist Professional serial bug killer