Date: Wed, 02 Nov 2011 12:32:18 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Benjamin Kaduk <kaduk@mit.edu> Cc: freebsd-current@FreeBSD.org, "K. Macy" <kmacy@FreeBSD.org>, Penta Upa <bsdboot@gmail.com> Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 Message-ID: <4EB11C32.80106@FreeBSD.org> In-Reply-To: <alpine.GSO.1.10.1111020203230.882@multics.mit.edu> References: <CAMsyT5QgHLqgSrt7qU_4FOVocW_GwmVWgZQ1A_CNrzkHQRTm4w@mail.gmail.com> <CAHM0Q_OWrQS_gnwupdJDwRFV9M3dKRN-SzkHgz6gJEedkvTPKQ@mail.gmail.com> <CAMsyT5Q5kMHRJQqFUdCCqqvKvFS_i5bvR8sHW6vNti_boD0nfA@mail.gmail.com> <alpine.GSO.1.10.1111020203230.882@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
> I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
> opt_global.h' to be passed on the command line. Is the issue just that the
> opt_global.h used for the kmod could be different from the actual kernel's
> opt_global.h, because KERNCONF was not specified and the header is generated at
> module-build time? In this case, clearly the onus is on the user to pass
> KERNCONF at module build time.
To be precise, this is what is actually passed to a compiler:
sys/conf/kmod.mk:
.if defined(KERNBUILDDIR)
CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h
.endif
where KERNBUILDDIR can be passed via environment from a kernel build:
sys/conf/kern.post.mk:
MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}"
KERNCONF does not have any meaning in a module build.
To make sure that a module build sees exactly the same kernel options as a
kernel with which the module should work, one has to either build the module
together with the kernel (within the kernel build; search for MODULES in
make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel
build directory. (Which to a certain degree implies impossibility to build a
"perfect" module for a pre-built binary kernel or to provide a "perfect"
universal pre-built module for any custom kernel)
Of course, the real problem is that modules should not care about any (or at
least some) kernel options, they should be isolated from the options via a
proper KPI/KBI (perhaps DDI or "module-to-kernel interface" or whatever). A
module should be able to work correctly with kernels built with different options.
As Bruce Evans has pointed to me privately [I am not sure why privately], there
is already an example in i386 and amd64 atomic.h, where operations are inlined
for a kernel build, but presented as real (external) functions for a module
build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
I think that the same treatment could/should be applied to vm_page_*lock*
operations defined in sys/vm/vm_page.h.
Or, if the above operations are intended to be used only in the kernel proper,
then there should be some guidelines on what API should module writers use to
perform certain page manipulations like e.g. wiring a page.
P.S. Bruce has also pointed out some other potentially dangerous places with
respect to the SMP option and modules build. Most prominent is sys/sys/mutex.h
P.P.S. [and tangential] I see that many module makefiles fake up various kernel
options in a fashion similar to the following:
.if !defined(KERNBUILDDIR)
opt_compat.h:
echo "#define COMPAT_FREEBSD6 1" > ${.TARGET}
opt_kbd.h:
echo "#define KBD_INSTALL_CDEV 1" > ${.TARGET}
.endif
And handful of modules fake up opt_global.h, e.g.:
opt_global.h:
echo "#define ALTQ 1" > ${.TARGET}
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EB11C32.80106>