Mail Archives: cygwin/2011/01/12/07:03:52
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,T_TO_NO_BRKTS_FREEMAIL
|
X-Spam-Check-By: | sourceware.org
|
MIME-Version: | 1.0
|
In-Reply-To: | <20110112111520.GJ6353@calimero.vinschen.de>
|
References: | <AANLkTimioT4OZ7CfW1Kh7R1nWv7uKz6v_3w=Hcgv-J6D AT mail DOT gmail DOT com> <4D2C6AE0 DOT 1000703 AT redhat DOT com> <AANLkTin_qu-uidFWgas31-v4MwWqLbi75svwtO-cUKoZ AT mail DOT gmail DOT com> <20110112111520 DOT GJ6353 AT calimero DOT vinschen DOT de>
|
Date: | Wed, 12 Jan 2011 13:03:27 +0100
|
Message-ID: | <AANLkTimLuQRELg_xyahXN4kOGiToTb2Y2LmaHqBMvOGb@mail.gmail.com>
|
Subject: | Re: Adding madvise function in cygwin with a #define
|
From: | jdzstz - gmail dot com <jdzstz AT gmail DOT com>
|
To: | cygwin AT cygwin DOT com
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.com>
|
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
|
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
List-Archive: | <http://sourceware.org/ml/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
Sender: | cygwin-owner AT cygwin DOT com
|
Mail-Followup-To: | cygwin AT cygwin DOT com
|
Delivered-To: | mailing list cygwin AT cygwin DOT com
|
I have readed again the Linux man page
http://www.kernel.org/doc/man-pages/online/pages/man2/madvise.2.html
and perhaps the first text is outdated.
At the beginning of man page=A0it=A0says that:
"This call does not influence=A0the semantics of the application (except
in the case of MADV_DONTNEED), but=A0may influence its performance."
And "The kernel is free to ignore the advice."
But, in the other side, at the bottom it speaks about "flags which
affect the memory mapping behaviour on fork" as you said in your email
=3D> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, etc... and to ignore it
can be dangerous to application.
Maybe an implementation option could be:
1) Standard advices that only has a influence in application
performance, can be executed as current posix_madvise, checking only
the parameters and doing nothing =3D> MADV_NORMAL, MADV_SEQUENTIAL,
MADV_RANDOM, MADV_REMOVE, MADV_WILLNEED, MADV_DONTNEED
2) Rest of advices, that can modify the behaviour of application and
generate errors or security problems, so madvise returns always
"EINVAL" (as you said in your mail) : MADV_REMOVE, MADV_DONTFORK,
MADV_DOFORK, MADV_HWPOISON, MADV_SOFT_OFFLINE, MADV_MERGEABLE,
MADV_UNMERGEABLE
To reduce problems with applications that uses advises of list number
2, this constants would be undefined, so if the aplication code make
for example an "madvise(p, sz, MADV_DONTFORK)" at least, the problem
will be detected at compilation time.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -