Skip to contentSkip to conversation

update mman.h in latest glibc cvs

parisc-linux Mike Frysinger 3 participants 5 messages Aug 25, 2006 – Aug 26, 2006 2 messages not in the archive

lore
Share & tools
lore
#0 lore raw

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
diff -u -p -r1.5 mman.h
@@ -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]

#3 lore raw
In reply to Mike Frysinger
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.h in 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

#4 lore raw
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]

#6 lore raw
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.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

I 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