libxc portability fixes

PATCH In review Christoph Egger 4 participants 10 messages Sep 19, 2007 – Sep 20, 2007

lore

Share & tools

lore

Christoph Egger

author

2007-09-19 13:19 UTC #0 lore raw

PATCH 1/1 libxc portability fixes

Hi!

Attached patch mainly contains portability fixes:
- use MAP_ANON, that is what both (BSD-)Unix and Linux have
- change last_error handling to use pthreads
- cleanup: No need to include <xen/sys/privcmd.h> a second time in xg_private.h

The patch is mainly based on a diff for NetBSD.

Signed-off-by Christoph Egger <[email protected]>

Signature · 12 lines

AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

tools/libxc/xc_dom_core.c +2 -2

diff -r a00cc97b392a tools/libxc/xc_dom_core.c
@@ -122,7 +122,7 @@ void *xc_dom_malloc_page_aligned(struct 
     memset(block, 0, sizeof(*block));
     block->mmap_len = size;
     block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,
+                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
                            -1, 0);
     if ( block->mmap_ptr == MAP_FAILED )
     {

@@ -354,7 +354,7 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_im
     {
         mode = "anonymous memory";
         phys->ptr = mmap(NULL, phys->count << page_shift,
-                         PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,
+                         PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
                          -1, 0);
         if ( phys->ptr == MAP_FAILED )
         {

tools/libxc/xc_private.c +80 ~~-14~~

154 lines not on this page · raw message

tools/libxc/xg_private.h +0 -1

diff -r a00cc97b392a tools/libxc/xg_private.h
@@ -15,7 +15,6 @@
 #include "xenguest.h"
 #include "xc_private.h"
 
-#include <xen/sys/privcmd.h>
 #include <xen/memory.h>
 #include <xen/elfnote.h>

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Vincent Hanquez

2007-09-19 14:25 UTC #1 lore raw

Quoted 2 lines · Christoph Egger

Attached patch mainly contains portability fixes:
- use MAP_ANON, that is what both (BSD-)Unix and Linux have

looks like that might bite us back at some point:

man mmap:
MAP_ANON
Synonym for MAP_ANONYMOUS. Deprecated.

what about:

#ifndef MAP_ANONYMOUS
#define MAP_ANONYMOUS MAP_ANON
#endif

Cheers,

Signature · 1 line

Vincent Hanquez

Christoph Egger

author

2007-09-19 14:32 UTC #2 lore raw

Quoted 9 lines · On Wednesday 19 September 2007 16:25:15 Vincent Hanquez wrote:

Quoted 2 lines · Christoph Egger
Attached patch mainly contains portability fixes:
- use MAP_ANON, that is what both (BSD-)Unix and Linux have
looks like that might bite us back at some point:
man mmap:
MAP_ANON
Synonym for MAP_ANONYMOUS. Deprecated.

MAP_ANONYMOUS is the proprietary thing. The glibc people should know that and should deprecate MAP_ANONYMOUS instead. They should also document that the fd argument must be -1 when MAP_ANON is specified to match the Unix behaviour.

Christoph

Signature · 12 lines

AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Vincent Hanquez

2007-09-19 14:49 UTC #3 lore raw

Quoted 1 line · Christoph Egger

MAP_ANONYMOUS is the proprietary thing.

which "proprietary thing" ?

Quoted 2 lines

The glibc people
should know that and should deprecate MAP_ANONYMOUS instead.

solaris has deprecated MAP_ANON as well.

Quoted 2 lines

They should also document that the fd argument must be -1 when MAP_ANON is specified to match the Unix behaviour.

----------
MAP_ANONYMOUS

The mapping is not backed by any file; its contents are initial‐ ized to zero. The fd and offset arguments are ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is only supported on Linux since kernel 2.4.
----------

what are you missing from this ?

Cheers,

Signature · 1 line

Vincent Hanquez

Christoph Egger

author

2007-09-19 15:04 UTC #4 lore raw

Quoted 9 lines · On Wednesday 19 September 2007 16:49:49 Vincent Hanquez wrote:

Quoted 1 line · Christoph Egger
MAP_ANONYMOUS is the proprietary thing.
which "proprietary thing" ?
Quoted 2 lines
The glibc people
should know that and should deprecate MAP_ANONYMOUS instead.
solaris has deprecated MAP_ANON as well.

Oh, SystemV Unix has MAP_ANONYMOUS?
BSD-Unix only has MAP_ANON.

Quoted 14 lines

Quoted 2 lines
They should also document that the fd argument must be -1 when MAP_ANON is specified to match the Unix behaviour.
----------
MAP_ANONYMOUS
The mapping is not backed by any file; its contents are initial‐ ized to zero. The fd and offset arguments are ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is only supported on Linux since kernel 2.4.
----------

Quoted 1 line

what are you missing from this ?

My linux mmap manpage says:
---------------------------
MAP_ANONYMOUS
The mapping is not backed by any file; the fd and offset argu- ments are ignored. The use of this flag in conjunction with MAP_SHARED is only supported on Linux since kernel 2.4.

MAP_ANON
Alias for MAP_ANONYMOUS. Deprecated.
---------------------------

My bsd mmap manpage says:
-------------------------------
MAP_ANON Map anonymous memory not associated with any specific
file. The file descriptor is not used for creating MAP_ANON regions, and must be specified as -1. The mapped memory will be zero filled.
-------------------------------

Christoph

Signature · 12 lines

AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Vincent Hanquez

2007-09-19 15:41 UTC #5 lore raw

Quoted 4 lines · Christoph Egger

Quoted 1 line
solaris has deprecated MAP_ANON as well.
Oh, SystemV Unix has MAP_ANONYMOUS?
BSD-Unix only has MAP_ANON.

I've no idea, but I imagine this was deprecated for a reason on 2 very different systems. and looks like HP-UX only has MAP_ANONYMOUS.

some random google searching:
http://www.winehq.org/pipermail/wine-devel/2004-December/031636.html

classic unix mess i'ld say :(

Quoted 10 lines

My linux mmap manpage says:
---------------------------
MAP_ANONYMOUS
The mapping is not backed by any file; the fd and offset argu- ments are ignored. The use of this flag in conjunction with MAP_SHARED is only supported on Linux since kernel 2.4.
MAP_ANON
Alias for MAP_ANONYMOUS. Deprecated.
---------------------------

Yes, not good indeed.
The text i've pasted come from my linux debian manpage. you could file a bug to your distro to upgrade the manpages ;)

Cheers,

Signature · 1 line

Vincent Hanquez

Keir Fraser

2007-09-19 16:44 UTC #6 lore raw

I checked in the patch anyhow. If it causes problems then we can introduce some ifdef'ery.

- Keir

Quoted 32 lines · Vincent Hanquez

Quoted 4 lines · Christoph Egger
Quoted 1 line
solaris has deprecated MAP_ANON as well.
Oh, SystemV Unix has MAP_ANONYMOUS?
BSD-Unix only has MAP_ANON.
I've no idea, but I imagine this was deprecated for a reason on 2 very different systems. and looks like HP-UX only has MAP_ANONYMOUS.
some random google searching:
http://www.winehq.org/pipermail/wine-devel/2004-December/031636.html
classic unix mess i'ld say :(
Quoted 9 lines
My linux mmap manpage says:
---------------------------
MAP_ANONYMOUS
The mapping is not backed by any file; the fd and offset
argu-
ments are ignored. The use of this flag in conjunction
with
MAP_SHARED is only supported on Linux since kernel 2.4.
Quoted 3 lines
MAP_ANON
Alias for MAP_ANONYMOUS. Deprecated.
---------------------------
Yes, not good indeed.
The text i've pasted come from my linux debian manpage. you could file a bug to your distro to upgrade the manpages ;)
Cheers,

John Levon

2007-09-19 22:21 UTC #7 lore raw

In reply to Vincent Hanquez

Quoted 4 lines · Vincent Hanquez

Quoted 2 lines
The glibc people
should know that and should deprecate MAP_ANONYMOUS instead.
solaris has deprecated MAP_ANON as well.

We don't even *document* MAP_ANONYMOUS. Where did you get this impression from?

regards
john

Vincent Hanquez

2007-09-20 12:30 UTC #8 lore raw

Quoted 9 lines · John Levon

Quoted 4 lines · Vincent Hanquez
Quoted 2 lines
The glibc people
should know that and should deprecate MAP_ANONYMOUS instead.
solaris has deprecated MAP_ANON as well.
We don't even *document* MAP_ANONYMOUS. Where did you get this impression from?

I actually found that on 2 differents MLs (blender and wine to name them) by some random googling to find the reason it was deprecated on linux (which i still don't know).

Cheers,

Signature · 1 line

Vincent Hanquez

John Levon

2007-09-20 16:41 UTC #9 lore raw

Quoted 11 lines · Vincent Hanquez

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
The glibc people
should know that and should deprecate MAP_ANONYMOUS instead.
solaris has deprecated MAP_ANON as well.
We don't even *document* MAP_ANONYMOUS. Where did you get this impression from?
I actually found that on 2 differents MLs (blender and wine to name them) by some random googling to find the reason it was deprecated on linux (which i still don't know).

Appears to be hearsay... as far as I can tell, GNU libc's attempt to deprecate it is unilateral.

regards
john