update mman.h in latest glibc cvs
Carlos: for future hppa patches, would you prefer i send to libc-ports or to the parisc list ?
this patch is against latest mman.h in the ports cvs ... the one in the parisc cvs is a little bit more outdated
-mike
Index: sysdeps/unix/sysv/linux/hppa/bits/mman.h
===================================================================
RCS file: /cvs/glibc/ports/sysdeps/unix/sysv/linux/hppa/bits/mman.h,v retrieving revision 1.5
unix/sysv/linux/hppa/bits/mman.h +47 -34
@@ -34,40 +34,66 @@#define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE 0x02/* Changes are private */ -#define MAP_TYPE 0x03/* Mask for type of mapping */ +#ifdef __USE_MISC +# define MAP_TYPE 0x03/* Mask for type of mapping */ +#endif + +/* Other flags. */ #define MAP_FIXED 0x04/* Interpret addr exactly */ -#define MAP_ANONYMOUS 0x10/* don't use a file */ +#ifdef __USE_MISC +# define MAP_FILE 0 +# define MAP_ANON MAP_ANONYMOUS +# define MAP_ANONYMOUS 0x10/* don't use a file */ +#endif -#define MAP_DENYWRITE 0x0800/* ETXTBSY */ -#define MAP_EXECUTABLE 0x1000/* mark it as an executable */ -#define MAP_LOCKED 0x2000/* pages are locked */ -#define MAP_NORESERVE 0x4000/* don't check for reservations */ -#define MAP_GROWSDOWN 0x8000/* stack-like segment */ -#define MAP_POPULATE 0x10000/* populate (prefault) pagetables */ -#define MAP_NONBLOCK 0x20000/* do not block on IO */ +/* These are Linux-specific. */ +#ifdef __USE_MISC +# define MAP_DENYWRITE 0x0800/* ETXTBSY */ +# define MAP_EXECUTABLE 0x1000/* mark it as an executable */ +# define MAP_LOCKED 0x2000/* pages are locked */ +# define MAP_NORESERVE 0x4000/* don't check for reservations */ +# define MAP_GROWSDOWN 0x8000/* stack-like segment */ +# define MAP_POPULATE 0x10000/* populate (prefault) pagetables */ +# define MAP_NONBLOCK 0x20000/* do not block on IO */ +#endif +/* Flags to `msync'. */ #define MS_SYNC 1/* synchronous memory sync */ #define MS_ASYNC 2/* sync memory asynchronously */ #define MS_INVALIDATE 4/* invalidate the caches */ -#define MCL_CURRENT 1/* lock all current mappings */ -#define MCL_FUTURE 2/* lock all future mappings */ +/* Flags for `mlockall'. */ +#define MCL_CURRENT 1/* Lock all currently mapped pages. */ +#define MCL_FUTURE 2/* Lock all additions to address +space. */ -/* Advice to "madvise" */ +/* Flags for `mremap'. */ +#ifdef __USE_GNU +# define MREMAP_MAYMOVE 1 +# define MREMAP_FIXED 2 +#endif + +/* Advice to `madvise'. */ #ifdef __USE_BSD -# define MADV_NORMAL 0/* no further special treatment */ -# define MADV_RANDOM 1/* expect random page references */ -# define MADV_SEQUENTIAL 2/* expect sequential page references */ -# define MADV_WILLNEED 3/* will need these pages */ -# define MADV_DONTNEED 4/* dont need these pages */ -# define MADV_SPACEAVAIL 5/* insure that resources are reserved */ -# define MADV_VPS_PURGE 6/* Purge pages from VM page cache */ -# define MADV_VPS_INHERIT 7/* Inherit parents page size */ -# define MADV_REMOVE 9/* Remove these pages and resources. */ +# define MADV_NORMAL 0/* No further special treatment. */ +# define MADV_RANDOM 1/* Expect random page references. */ +# define MADV_SEQUENTIAL 2/* Expect sequential page references. */ +# define MADV_WILLNEED 3/* Will need these pages. */ +# define MADV_DONTNEED 4/* Don't need these pages. */ +# define MADV_REMOVE 9/* Remove these pages and resources. */ # define MADV_DONTFORK 10/* Do not inherit across fork. */ # define MADV_DOFORK 11/* Do inherit across fork. */ #endif +/* The POSIX people had to invent similar names for the same things. */ +#ifdef __USE_XOPEN2K +# define POSIX_MADV_NORMAL 0/* No further special treatment. */ +# define POSIX_MADV_RANDOM 1/* Expect random page references. */ +# define POSIX_MADV_SEQUENTIAL 2/* Expect sequential page references. */ +# define POSIX_MADV_WILLNEED 3/* Will need these pages. */ +# define POSIX_MADV_DONTNEED 4/* Don't need these pages. */ +#endif +/* The range 12-64 is reserved for page size specification. */ #define MADV_4K_PAGES 12/* Use 4K pages */ #define MADV_16K_PAGES 14/* Use 16K pages */
@@ -77,16 +103,3 @@#define MADV_4M_PAGES 22/* Use 4 Megabyte pages */ #define MADV_16M_PAGES 24/* Use 16 Megabyte pages */ #define MADV_64M_PAGES 26/* Use 64 Megabyte pages */ - -/* compatibility flags */ -#define MAP_ANON MAP_ANONYMOUS -#define MAP_FILE 0 -#define MAP_VARIABLE 0 - -/* Flags for `mremap'. */ -#ifdef __USE_GNU -# define MREMAP_MAYMOVE 1 -# define MREMAP_FIXED 2 -#endif - -
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Michael S. Zick
Those are the pages which would need the 'o' bit set for the newest processors.
Michael,
Please read:
http://lists.parisc-linux.org/pipermail/parisc-linux/2003-February/019183.html
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2004-August/034461.html
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 5 lines · Mike Frysinger
Carlos: for future hppa patches, would you prefer i send to libc-ports or to the parisc list ?
this patch is against latest
mman.hin the ports cvs ... the one in the parisc cvs is a little bit more outdated
I'm the libc-ports hppa maintainer, and posting to libc-ports is the correct procedure. If you would like you can also CC parisc-linux to keep people up to date on changes.
There are a couple of problems with your patch:
1. You need a ChangeLog.
2. You will need FSF assignments if you don't already have them for GLIBC.
3. Feel free to respond to the following..
The following is a bug.
+# define MAP_ANON MAP_ANONYMOUS
+# define MAP_ANONYMOUS 0x10 /* don't use a file */
Please avoid superflous style changes.
-/* Advice to "madvise" */
+/* Advice to `madvise'. */
Are you sure nothing uses these?
-#define MAP_VARIABLE 0
-# define MADV_VPS_PURGE 6 /* Purge pages from VM page cache */
-# define MADV_VPS_INHERIT 7 /* Inherit parents page size */
Thanks for working on updating mman.h!
What we really need is people building glibc and debugging 'make -k check' failures! :)
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 1 line · Carlos O'Donell
1. You need a ChangeLog.
indeed ... i wanted to see if the patch was correct first as writing ChangeLog entries is boring ;)
Quoted 1 line
2. You will need FSF assignments if you don't already have them for GLIBC.
i dont have in place specifically for glibc, ive just contributed my previous things as "small" and/or "obvious" ... i can simply release into the public domain; all that matters to me is that things get fixed
unix/sysv/linux/hppa/bits/mman.h line 46
Quoted 3 lines
The following is a bug.
unix/sysv/linux/hppa/bits/mman.h +2
-0+# define MAP_ANON MAP_ANONYMOUS +# define MAP_ANONYMOUS 0x10/* don't use a file */
yes, that should be reversed
Quoted 1 line
Please avoid superflous style changes.
it isnt superfluous, it is the "GNU standard" and the way all other arch mman.h headers are done ... so while i personally consider the GNU coding standard complete garbage, glibc is a GNU project and adheres pretty rigidly to the GNU coding standard
unix/sysv/linux/hppa/bits/mman.h line 65
Quoted 4 lines
Are you sure nothing uses these?
unix/sysv/linux/hppa/bits/mman.h +0
-3-#define MAP_VARIABLE 0 -# define MADV_VPS_PURGE 6/* Purge pages from VM page cache */ -# define MADV_VPS_INHERIT 7/* Inherit parents page size */
i was syncing to other architectures ... but since parisc is the only one (in the kernel headers) that defines these three, i guess it's appropriate to keep them for parisc
-mike
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Carlos O'Donell
I appreciate it if you say "Is this patch correct?" or some indication that it is not final. I spend a different amount of time reviewing final patches than just initial hacks.
sorry, my mistake ... i'll keep that in mind in the future
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Please avoid superflous style changes.
it isnt superfluous, it is the "GNU standard" and the way all other arch
mman.hheaders are done ... so while i personally consider the GNU coding standard complete garbage, glibc is a GNU project and adheres pretty rigidly to the GNU coding standardI don't see a requirement for left single quote and right single quote in comments?
as i said i was simply doing exactly what every other arch port in glibc is doing ... if you want to keep hppa different, well you're the maintainer ;)
Quoted 2 lines
Thank you. Could you put together another patch please? If you haven't done a build test please tell me.
i just do cross-compile builds as my hppa's are too painfully slow to do development natively :)
-mike
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux