Re: A mmap64 patch

["H . J . Lu" <hjl at lucon dot org>]

On Sun, May 27, 2001 at 07:34:59PM -0700, Geoff Keating wrote:
> > 
> > Which one? If you meant
> > 
> > http://sources.redhat.com/ml/libc-alpha/2001-05/msg00265.html
> > 
> > then see
> > 
> > http://sources.redhat.com/ml/libc-alpha/2001-05/msg00271.html
> 
> Your reply didn't seem to make sense.
> 
> The code in sysdeps/unix/sysv/linux is for new ports.  Old ports that

Wrong. The code in sysdeps/unix/sysv/linux is for ports with 32bit
offset. All ports with 64bit offset, new and old, should have a dummy
mmap64.c like

---
/* mmap64 is the same as mmap. */
---

in the port-specific dircetory.

> need backwards compatibility use routines in port-specific
> directiories.

Let's see what my patch does:

1. It removes mmap64.c for ppc, sparc64 and hppa.
2. It updates mmap64.c in sysdeps/unix/sysv/linux to support all
ports with 32bit offset.

Which one do you think not to make sense? BTW, that is the way we
handle all other xxx64 functions. A port can define its own xxx64
file if it has to be handled differently from other ports with 32bit
offset. My patch doesn't mean the new port with 64bit offset doesn't
need a dummy mmap64.c. A dummy mmap64.c is required for a port with
32bit offset. It has nothing to do with my patch.

> 
> New ports should not have a mmap2() system call at all.  Instead, they
> should have a mmap() system call that takes a 64-bit offset.  Their
> mmap64() library routine should be just a direct system call, and so
> either they don't need any mmap64.c file at all or it should be a
> dummy file.

I don't think it is the way glibc does xxx64 function. We always have
a dummy xxx64.c file if xxx is thes same as xxx64. In any case, what
does it have anything to do with my patch?


H.J.