Date: Wed, 20 Mar 2002 14:38:46 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: BOUWSMA Beery <freebsd-user@dcf77-zeit.netscum.dyndns.dk> Cc: hackers@freebsd.org, Jonathan Buzzard <jonathan@buzzard.org.uk> Subject: Re: How to correctly detect POSIX 1003.1b features on FreeBSD? Message-ID: <3C990F76.B66BEBF9@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <wollman@FreeBSD.org>. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C990F76.B66BEBF9>