sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon
Merge i386 and amd64 mtrr drivers.Reviewed by: royger, jhbSponsored by: The FreeBSD FoundationMFC after: 2 weeksDifferential 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: mariusTested 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: mariusTested by: sbrunoApproved 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 nowunnecessary 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 nowunnecessary dev_mem_md_init(). Consistently define mem_range_softc frommem.c for all platforms. Add missing #include guards for machine/memdev.hand sys/memrange.h. Clean up some nearby style(9) nits.MFC after: 1 month
Unbreak build.
Add a memory-range interface to /dev/mem on PowerPC using PAT attributes.Unlike actual MTRR, this only controls the mapping attributes forsubsequent 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 forsubsequent mmap() of /dev/mem. Nonetheless, the support is sufficientlyMTRR-like that Xorg can use it, which translates into an enormous increasein graphics performance on PowerPC.MFC after: 2 weeks
MFtbemd:Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is thesource code location of the machine, the latter the binary output. Ingeneral, we want to use MACHINE_CPUARCH instead
MFtbemd:Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is thesource code location of the machine, the latter the binary output. Ingeneral, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unlesswe're tesitng for a specific target. The isn't even moot fori386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,although a specific cleanup for that likely would be needed...
Prefer the opt_global.h from KERNBUILDDIR if existent so we obtain allmacros 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 thatmachine-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 thatmachine-specific files take precedence of architecture-specific ones.This fixes the build on sun4v which doesn't use the sparc64 versionof mem.c.Tested by: make universe
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 intotheir own directory and module, leaving the MD parts in the MDarea (the MD parts _are_ part of the modules). /dev/mem and /dev/ioar
Break out the MI part of the /dev/[k]mem and /dev/io drivers intotheir own directory and module, leaving the MD parts in the MDarea (the MD parts _are_ part of the modules). /dev/mem and /dev/ioare now loadable modules, thus taking us one step further towardsa kernel created entirely out of modules. Of course, there is nothingpreventing the kernel from having these statically compiled.