Make support for atomics on ARM complete.

Provide both __sync_*-style and __atomic_*-style functions that perform
the atomic operations on ARMv5 by using Restartable Atomic Sequences.

While there, clean up some pieces of code where it's sufficient to use
regular uint32_t to store register contents and don't need full reg_t's.
Also sync this back to the MIPS code.


git-svn-id: svn://svn.freebsd.org/base/head@251781 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Stick to using the documented atomic(9) API.

The atomic_store_ptr() function is not part of the atomic(9) API. We
only provide a version with a release barrier.


git-svn-id: svn://svn.freebsd.org/base/head@251782 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Remove conflicting macros from SPARC64's atomic(9) header.

The atomic_load() and atomic_store() macros conflict with the equally
named macros from <stdatomic.h>. Remove them, as they are only used to
implement functions that are not present on any of the other
architectures.


git-svn-id: svn://svn.freebsd.org/base/head@251783 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Let ARM use the custom tailored atomic intrinsics.


git-svn-id: svn://svn.freebsd.org/base/head@251784 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Pull in r184040 from upstream clang trunk:

  Emit native implementations of atomic operations on FreeBSD/armv6.

  Just like on Linux, FreeBSD/armv6 assumes the system supports
  ldrex/strex unconditionally. It is also used by the kernel. We can
  therefore enable support for it, like we do on Linux.

  While there, change one of the unit tests to explicitly test against
  armv5 instead of armv7, as it actually tests whether libcalls are
  emitted.


git-svn-id: svn://svn.freebsd.org/base/head@251785 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Move hhook's per-vnet initialisation to an earlier SYSINIT SI_SUB stage to
ensure all per-vnet related hhook initialisation is completed prior to any
virtualised hhook points attempting registration.

vnet_register_sysinit() requires that a stage later than SI_SUB_VNET be chosen.
There are no per-vnet initialisors in the source tree at this time which run
earlier than SI_SUB_INIT_IF. A quick audit of non-virtualised SYSINITs indicates
there are no subsystems pre SI_SUB_MBUF that would likely be interested in
registering a virtualised hhook point.

Settle on SI_SUB_MBUF as hhook's per-vnet initialisation stage as it's the first
overtly network-related initilisation stage to run after SI_SUB_VNET. If a
subsystem that initialises earlier than SI_SUB_MBUF ends up wanting to register
virtualised hhook points in future, hhook's use of SI_SUB_MBUF will need to be
revisited and would probably warrant creating a dedicated SI_SUB_HHOOK which
runs immediately after SI_SUB_VNET.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@251787 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Now that the necessary infrastructure is in place to ensure hhook points which
register after a khelp module will get hooked, move khelp module initialisation
to the earlier SI_SUB_KLD stage.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@251789 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Pull in r183926 from LLVM trunk:

  Allow clang to build __clear_cache on ARM.

  __clear_cache is special. It needs no signature, but is a real function in
  compiler_rt or libgcc.

  Patch by Andrew Turner.

This allows us to build the __clear_cache function in compiler-rt.


git-svn-id: svn://svn.freebsd.org/base/head@251790 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Build __clear_cache on ARM with clang now it supports it.


git-svn-id: svn://svn.freebsd.org/base/head@251791 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Restore use of polling mode for disk cache flush in case of kernel panic.
While I am not sure that any extra hardware access is a good idea after
panic, that is an existing behaviour that should better work correctly.


git-svn-id: svn://svn.freebsd.org/base/head@251792 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Style/comments.


git-svn-id: svn://svn.freebsd.org/base/head@251793 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Remove CVS from the base system.

Discussed with:	many
Reviewed by:	peter, zi
Approved by:	core


git-svn-id: svn://svn.freebsd.org/base/head@251794 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Regenerate after CVS removal (and it seems other missed changes)


git-svn-id: svn://svn.freebsd.org/base/head@251795 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Let hastd use C11 atomics.

C11 atomics now work on all the architectures. Have at least a single
piece of software in our base system that uses C11 atomics. This
somewhat makes it less likely that we break it because of LLVM imports,
etc.


git-svn-id: svn://svn.freebsd.org/base/head@251796 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sh: Add tests for 'local -' (save shell options).


git-svn-id: svn://svn.freebsd.org/base/head@251797 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Return ENETDOWN when the parent interface is down.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@251799 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
cvsweb -> svnweb


git-svn-id: svn://svn.freebsd.org/base/head@251801 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Change callout use counter to use C11 atomics.

In order to get some coverage of C11 atomics in kernelspace, switch at
least one piece of code in kernelspace to use C11 atomics instead of
<machine/atomic.h>.

While there, slightly improve the code by adding an assertion to prevent
the use count from going negative.


git-svn-id: svn://svn.freebsd.org/base/head@251803 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Move _Atomic() into <sys/cdefs.h>.

That way _Atomic() is defined next to all the other C11 keywords for
which we provide compatibility for pre-C11 compilers. While there, fix
the definition to place "volatile" at the end. Otherwise pointer types
will become "volatile T *" instead of "T * volatile".


git-svn-id: svn://svn.freebsd.org/base/head@251804 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/xen/blkfront/blkfront.c:
	In xbd_thaw(), fix inverted logic to verify the queue is frozen
	before attempting a thaw.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@251807 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f