in a separate word from the _count. This does not permit both items to
be updated atomically in a portable manner. As a result, sem_post()
must always perform a system call to safely clear _has_waiters.
This change removes the _has_waiters field and instead uses the high bit
of _count as the _has_waiters flag. A new umtx object type (_usem2) and
two new umtx operations are added (SEM_WAIT2 and SEM_WAKE2) to implement
these semantics. The older operations are still supported under the
COMPAT_FREEBSD9/10 options. The POSIX semaphore API in libc has
been updated to use the new implementation. Note that the new
implementation is not compatible with the previous implementation.
However, this only affects static binaries (which cannot be helped by
symbol versioning). Binaries using a dynamic libc will continue to work
fine. SEM_MAGIC has been bumped so that mismatched binaries will error
rather than corrupting a shared semaphore. In addition, a padding field
has been added to sem_t so that it remains the same size.
Differential Revision: https://reviews.freebsd.org/D961
Reported by: adrian
Reviewed by: kib, jilles (earlier version)
Sponsored by: Norse
In some cases, TSC is broken and special applications might benefit
from memory mapping HPET and reading the registers to count time.
Most often the main HPET counter is 32-bit only[1], so this only gives
the application a 300 second window based on the default HPET
interval.
Other applications, such as Intel's DPDK, expect /dev/hpet to be
present and use it to count time as well.
Although we have an almost userland version of gettimeofday() which
uses rdtsc in userland, it's not always possible to use it, depending
on how broken the multi-socket hardware is.
Install the acpi_hpet.h so that applications can use the HPET register
definitions.
[1] I haven't found a system where HPET's main counter uses more than
32 bit. There seems to be a discrepancy in the Intel documentation
(claiming it's a 64-bit counter) and the actual implementation (a
32-bit counter in a 64-bit memory area).
MFC after: 1 week
Relnotes: yes
I've looked at the GCC sources and I now understand what's going wrong.
THe C11 keywords are simply nonexistent when using C++ mode. They are
marked as C-only in the parser. This is absolutely impractical for
multiple reasons:
- The C11 keywords do not conflict with C++ naming rules. They all start
with _[A-Z]. There is no reason to make them C-only.
- It makes it practically impossible for people to use these keywords in
C header files and expect them to work from within C++ sources.
As I said in my previous commit message: GCC is by far the weirdest
compiler that I've ever used.
As GCC also gained support for the C11 keywords over time, we can patch
up <sys/cdefs.h> to not define these anymore. This has the advantage
that error messages for static assertions are printed natively and that
_Alignas() will work with even a type outside of C11 mode.
All C11 keywords are supported with GCC 4.7 and higher, with the
exception of _Thread_local and _Generic. These are only supported as of
GCC 4.9.
bsearch_b is the Apple blocks enabled version of bsearch(3).
This was added to libc in Revision 264042 but the commit
missed the declaration required to make use of it.
While here move some other block-related functions to the
BSD_VISIBLE block as these are non-standard.
Phabric: D638
Reviewed by: theraven, wollman
This change extends all of the functions present in the <pthread.h> and
<threads.h> headers to have lock annotations. This will allow Clang to
warn about the following:
- Locking a function twice,
- Unlocking a function without a mutex being locked,
- Forgetting to unlock a mutex before returning,
- Destroying or reinitializing a mutex that is currenty locked,
- Using an unlocked mutex in combination with a condition variable.
Enabling these annotations already allowed me to catch a bug in one of
our userspace tools (r270749).
Back in 2011 obrien has added the #define macro in sys/sys/stddef.h to
guard ptrdiff_t. Add similar protection to the identical code in
include/stddef.h.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
MFC after: 1 week
From
http://www.isc.org/downloads/libbind/
The libbind functions have been separated from the BIND suite as of BIND
9.6.0. Originally from older versions of BIND, they have been continually
maintained and improved but not installed by default with BIND 9. This
standard resolver library contains the same historical functions and
headers included with many Unix operating systems. In fact, most
implementations are based on the same original code.
At present, NetBSD maintains libbind code, now known as "netresolv".
While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.
Obtained from: NetBSD (hcreate.c, CVS Rev. 1.7)
The current ordering of this header is a feature as it
is more consistent with POSIX.
Also adding gratuitous newlines is not elegant.
Pointed out by: bde
- In the unionfs case, opendir() and fdopendir() read the directory's full
contents and cache it. This cache is not refreshed when rewinddir() is
called, so rewinddir() will not notice updates to a directory. Fix this
by splitting the code to fetch a directory's contents out of
__opendir_common() into a new _filldir() function and call this from
rewinddir() when operating on a unionfs directory.
- If rewinddir() is called on a directory opened with fdopendir() before
any directory entries are fetched, rewinddir() will not adjust the seek
location of the backing file descriptor. If the file descriptor passed
to fdopendir() had a non-zero offset, the rewinddir() will not rewind to
the beginning. Fix this by always seeking back to 0 in rewinddir().
This means the dd_rewind hack can also be removed.
While here, add missing locking to rewinddir().
CR: https://phabric.freebsd.org/D312
Reviewed by: jilles
MFC after: 1 week
POSIX.1-2008 specifies that those two functions should be declared by
including <strings.h>, not <string.h> (the latter only has strcoll_l()
and strxfrm_l()):
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcasecmp.html
Obtained from: DragonFlyBSD
Reviewed by: theraven
MFC after: 2 weeks
The CUSE library is a wrapper for the devfs kernel functionality which
is exposed through /dev/cuse . In order to function the CUSE kernel
code must either be enabled in the kernel configuration file or loaded
separately as a module. Currently none of the committed items are
connected to the default builds, except for installing the needed
header files. The CUSE code will be connected to the default world and
kernel builds in a follow-up commit.
The CUSE module was written by Hans Petter Selasky, somewhat inspired
by similar functionality found in FUSE. The CUSE library can be used
for many purposes. Currently CUSE is used when running Linux kernel
drivers in user-space, which need to create a character device node to
communicate with its applications. CUSE has full support for almost
all devfs functionality found in the kernel:
- kevents
- read
- write
- ioctl
- poll
- open
- close
- mmap
- private per file handle data
Requested by several people. Also see "multimedia/cuse4bsd-kmod" in
ports.
or __POSIX_VISIBLE.
Whenever <sys/cdefs.h> sets __BSD_VISIBLE to non-zero, it also sets
__POSIX_VISIBLE and __XSI_VISIBLE to the newest version supported.
No functional change is intended.
AppleTalk was a network transport protocol for Apple Macintosh devices
in 80s and then 90s. Starting with Mac OS X in 2000 the AppleTalk was
a legacy protocol and primary networking protocol is TCP/IP. The last
Mac OS X release to support AppleTalk happened in 2009. The same year
routing equipment vendors (namely Cisco) end their support.
Thus, AppleTalk won't be supported in FreeBSD 11.0-RELEASE.
IPX was a network transport protocol in Novell's NetWare network operating
system from late 80s and then 90s. The NetWare itself switched to TCP/IP
as default transport in 1998. Later, in this century the Novell Open
Enterprise Server became successor of Novell NetWare. The last release
that claimed to still support IPX was OES 2 in 2007. Routing equipment
vendors (e.g. Cisco) discontinued support for IPX in 2011.
Thus, IPX won't be supported in FreeBSD 11.0-RELEASE.
device is an active kernel console and "off" otherwise. This is designed to
allow serial-booting x86 systems to provide a login prompt on the serial line
by default without providing one on all systems by default.
Comments and suggestions by: grehan, dteske, jilles
MFC after: 1 month
3-clause BSD license as specified by Oracle America, Inc. in 2010.
This license change was approved by Wim Coekaerts, Senior Vice
President, Linux and Virtualization at Oracle Corporation.
when there is an invalid character in the output codeset while it is
valid in the input. However, POSIX requires iconv() to perform an
implementation-defined conversion on the character. So, Citrus iconv converts
such a character to a special character which means it is invalid in the
output codeset.
This is not a problem in most cases but some software like libxml2 depends
on GNU's behavior to determine if a character is output as-is or another form
such as a character entity (&#NNN;).
FreeBSD systems usually implemented this as a third party module and
our implementation hasn't played as nicely with the old way as it could
have.
To that end:
* Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix.
* Provide .symver compatability with existing 10.x+ binaries that
referenced the iconv symbols. All existing binaries should work.
* Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript
at /usr/lib/libc.so.
* Move the "iconv*" wrapper symbols to libc_nonshared.a
This should solve the runtime ambiguity about which symbols resolve
to where. If you compile against the iconv in libc, your runtime
dependencies will be unambiguous.
Old 9.x libraries and binaries will always resolve against their
libiconv.so.3 like they did on 9.x. They won't resolve against libc.
Old 10.x binaries will be satisified by the .symver helpers.
This should allow ports to selectively compile against the libiconv
port if needed and it should behave without ambiguity now.
Discussed with: kib
good. This caused libc to spoof the ports libiconv namespace and
provide a colliding libiconv.so.3 to fool rtld. This should have
been removed some time ago.
in net, to avoid compatibility breakage for no sake.
The future plan is to split most of non-kernel parts of
pfvar.h into pf.h, and then make pfvar.h a kernel only
include breaking compatibility.
Discussed with: bz
newvers.sh. Pass it in from include/Makefile. If it isn't passed in,
fall back to the old logic of using dirname $0.
Using dirname $0 does not yield the path to the script if it was
sourced in from another script in another directory; you end up with
the parent script's path. That was causing newvers.sh to look one
level below the FreeBSD src/ directory when building osreldate.h and it
may find something like a git or svn repo there that has nothing to do
with FreeBSD.
PR: 174422
Approved by: re ()
MFC after: 2 weeks
This would cause detection of old versions of SVN to cause fatal errors
instead of being caught and handled, which would make the build fail if
the tree had been checked out with an older version of SVN (e.g. 1.6).
Discussed with: gjb
Approved by: re (marius)
may come in from the environment and reflect the user's interactive shell.
Using bare "sh" is the dominant pattern in existing makefiles.
MFC this together with r255775.
Approved by: re ()
MFC after: 2 weeks
than launching the script directly and relying on #! to launch the shell.
This avoids problems when the source is mounted with the noexec flag.
MFC this together with r255775.
Approved by: re (kib)
MFC after: 2 weeks
newvers.sh into a temporary subshell with inline make rules.
Using a separate script fixes a variety of problems, including establishing
the correct dependencies in the makefiles. It also eliminates a problem
with the way newvers.sh uses `realpath $0`, because $0 expands differently
within a script sourced into a rule in a makefile depending on the version
of make and of /bin/sh being used. The latter can cause build breakage in a
cross-build environment, and can also make it difficult to compile 10.0 on
older pre-10.0 systems.
PR: 160646 174422
Submitted by: Garrett Cooper <yaneurabeya@gmail.com>
Approved by: re (gjb)
MFC after: 2 weeks
hrs@ provided this verison of the patch and showed me where all the needed
changes were to be made outside of gpioctl.c
Approved by: re (hrs)
MFC after: 2 weeks
