From owner-freebsd-hackers Wed Mar 20 14:39:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 6670237B417 for ; Wed, 20 Mar 2002 14:39:28 -0800 (PST) Received: from pool0107.cvx21-bradley.dialup.earthlink.net ([209.179.192.107] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16noja-0004RC-00; Wed, 20 Mar 2002 14:39:07 -0800 Message-ID: <3C990F76.B66BEBF9@mindspring.com> Date: Wed, 20 Mar 2002 14:38:46 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: BOUWSMA Beery Cc: hackers@freebsd.org, Jonathan Buzzard Subject: Re: How to correctly detect POSIX 1003.1b features on FreeBSD? References: <20020312140904.A799@bbn.com> <3C8E742C.7C2E63B8@mindspring.com> <20020312193514.A2226@bbn.com> <20020313005940.GB32410@elvis.mu.org> <20020312201314.A2345@bbn.com> <3C8EB31E.19382903@mindspring.com> <20020312214007.A2526@bbn.com> <200203201907.g2KJ71R03929@beerswilling.netscum.dyndns.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG BOUWSMA Beery wrote: > > [replies sent directly to me may timeout and bounce, since I'm not > online as often as I should be, but I'll check the list archives] > > I've followed this with interest, because I'm playing with some > Linux k0deZ which makes calls to m(un)lockall() that are similarly > wrapped in sys/mman.h by > | #ifdef _P1003_1B_VISIBLE > | int mlockall __P((int)); > | int munlockall __P((void)); > | int shm_open __P((const char *, int, mode_t)); > | int shm_unlink __P((const char *)); > | #endif /* _P1003_1B_VISIBLE */ [ ... ] > Anyway, when compiling this Linux program, which has lines [ ... ] > linking fails... Don't compile on Linux? 8-) 8-) > First question: Are mlockall() and munlockall() supported by FreeBSD > (tested with 4.5-stable above), and if so, what needs to be defined > as the magic incantation to be able to use them as above? They are stubbed out. > Secondly, if these calls aren't supported, what test, if not the > #ifdef _POSIX_REALTIME_SIGNALS test mentioned in the earlier > thread above, needs to be wrapped around the source k0deZ so that > FreeBSD goes to some alternate code, while Linux executes the above > m(un)lockall() calls, until FreeBSD does support these calls? They are part of POSIX REALTIME, not part of POSIX REALTIME signals. Not all of POSIX REALTIME is required to be implemented at the same time. And no matter what, you are not going to be able to tell stubbed out kernel functionality from real kernel functionality. For MCL_FUTURE, the spec. is so "impelmentation defined" that the current implementation in FreeBSD is compliant. 8-) 8-). The MCL_CURRENT is stubbed; the functions are basically an attempts to get around overcommit and swap based delays for RT code. Is your code controlling a nuclear reactor? No? Then it doesn't need the calls. 8-). I don't know the proper test off the top of my head, but I know who would know, and I know a test that works for m{un}lockall(), and both of those are better anyway. The person who would know would be Garrett A. Wollman; his email is . He would know because he's been on the committes, and he's know because he wrote the shm_open(3) library code... just like it says at the bottom of the man page for it. The test that works for m{un}lockall() requires that you: o Understand that munlockall() is the reverse of mlockall(), so if there is no mlockall(), then there is no munlockall(), and vice versa. o The mlockall() function takes a flags argument that is an inclusive OR of one of several manifest constants. So basically, if you test for the manifest constants before making a call that uses them, then you are safe, e.g.: #ifdef MCL_CURRENT mlockall( MCL_CURRENT); #endif ... #ifdef MCL_CURRENT munlockall(); #endif This should work everywhere, even on Linux, without having to break down and ask the person who wrote the code from the POSIX spec. to look at their copy of the POSIX spec., and tell you what the guard manifests are. Alternately, you could send an email to Garrett. 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message