opnsense-src/sys/modules/mem/Makefile

# $FreeBSD$

.PATH: ${.CURDIR}/../../dev/mem
.PATH: ${.CURDIR}/../../${MACHINE}/${MACHINE}
.PATH: ${.CURDIR}/../../${MACHINE_CPUARCH}/${MACHINE_CPUARCH}

KMOD=	mem
SRCS=	mem.c memdev.c memutil.c
.if ${MACHINE_CPUARCH} == "i386"
SRCS+=	i686_mem.c k6_mem.c
.endif
.if ${MACHINE_CPUARCH} == "amd64"
SRCS+=	amd64_mem.c
.endif
SRCS+=	bus_if.h device_if.h

.include <bsd.kmod.mk>
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. 2004-08-01 07:40:54 -04:00			`# $FreeBSD$`

			`.PATH: ${.CURDIR}/../../dev/mem`
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 2006-10-16 18:09:48 -04:00			`.PATH: ${.CURDIR}/../../${MACHINE}/${MACHINE}`
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... 2010-08-23 02:13:29 -04:00			`.PATH: ${.CURDIR}/../../${MACHINE_CPUARCH}/${MACHINE_CPUARCH}`
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. 2004-08-01 07:40:54 -04:00
			`KMOD= mem`
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 2011-01-17 17:58:28 -05:00			`SRCS= mem.c memdev.c memutil.c`
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... 2010-08-23 02:13:29 -04:00			`.if ${MACHINE_CPUARCH} == "i386"`
Add the memrange bits to the loadable module. MT5 after: 3 days 2004-09-28 03:26:00 -04:00			`SRCS+= i686_mem.c k6_mem.c`
			`.endif`
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... 2010-08-23 02:13:29 -04:00			`.if ${MACHINE_CPUARCH} == "amd64"`
Add the memrange bits to the loadable module. MT5 after: 3 days 2004-09-28 03:26:00 -04:00			`SRCS+= amd64_mem.c`
			`.endif`
No need to generate vnode_if.h anymore 2004-12-29 03:44:30 -05:00			`SRCS+= bus_if.h device_if.h`
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. 2004-08-01 07:40:54 -04:00
			`.include <bsd.kmod.mk>`