sys: Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

sys/modules: normalize .CURDIR-relative paths to SRCTOP

This simplifies make output/logic

Tested with: `cd sys/modules; make ALL_MODULES=` on amd64
MFC after: 1 month
Sponsored by: Dell EMC Isilon

Merge i386 and amd64 mtrr drivers.

Reviewed by: royger, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9648

Disconnect sun4v architecture from the three.

Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.

Reviewed by: marius
Tested b

Disconnect sun4v architecture from the three.

Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.

Reviewed by: marius
Tested by: sbruno
Approved by: re

show more ...

Add reader/writer lock around mem_range_attr_get() and mem_range_attr_set().
Compile sys/dev/mem/memutil.c for all supported platforms and remove now
unnecessary dev_mem_md_init(). Consistently defi

Add reader/writer lock around mem_range_attr_get() and mem_range_attr_set().
Compile sys/dev/mem/memutil.c for all supported platforms and remove now
unnecessary dev_mem_md_init(). Consistently define mem_range_softc from
mem.c for all platforms. Add missing #include guards for machine/memdev.h
and sys/memrange.h. Clean up some nearby style(9) nits.

MFC after: 1 month

show more ...

Unbreak build.

Add a memory-range interface to /dev/mem on PowerPC using PAT attributes.
Unlike actual MTRR, this only controls the mapping attributes for
subsequent mmap() of /dev/mem. Nonetheless, the support is

Add a memory-range interface to /dev/mem on PowerPC using PAT attributes.
Unlike actual MTRR, this only controls the mapping attributes for
subsequent mmap() of /dev/mem. Nonetheless, the support is sufficiently
MTRR-like that Xorg can use it, which translates into an enormous increase
in graphics performance on PowerPC.

MFC after: 2 weeks

show more ...

MFtbemd:

Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is the
source code location of the machine, the latter the binary output. In
general, we want to use MACHINE_CPUARCH instead

MFtbemd:

Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is the
source code location of the machine, the latter the binary output. In
general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless
we're tesitng for a specific target. The isn't even moot for
i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,
although a specific cleanup for that likely would be needed...

show more ...

Prefer the opt_global.h from KERNBUILDDIR if existent so we obtain all
macros that might be relevant.

For sun4v ensure there is an opt_global.h with SUN4V defined included,
even for the stand-alone build.

Add a .PATH entry to search for sources in the ${MACHINE}/${MACHINE}
directory before the ${MACHINE_ARCH}/${MACHINE_ARCH} directory so that
machine-specific files take precedence of architecture-spec

Add a .PATH entry to search for sources in the ${MACHINE}/${MACHINE}
directory before the ${MACHINE_ARCH}/${MACHINE_ARCH} directory so that
machine-specific files take precedence of architecture-specific ones.

This fixes the build on sun4v which doesn't use the sparc64 version
of mem.c.

Tested by: make universe

show more ...

No need to generate vnode_if.h anymore

Add the memrange bits to the loadable module.

MT5 after: 3 days

Fix module builds for i386 and amd64.

Break out the MI part of the /dev/[k]mem and /dev/io drivers into
their own directory and module, leaving the MD parts in the MD
area (the MD parts _are_ part of the modules). /dev/mem and /dev/io
ar

Break out the MI part of the /dev/[k]mem and /dev/io drivers into
their own directory and module, leaving the MD parts in the MD
area (the MD parts _are_ part of the modules). /dev/mem and /dev/io
are now loadable modules, thus taking us one step further towards
a kernel created entirely out of modules. Of course, there is nothing
preventing the kernel from having these statically compiled.

show more ...