Date: Thu, 03 Nov 2011 00:40:08 -0500 From: Alan Cox <alc@rice.edu> To: Andriy Gapon <avg@FreeBSD.org> Cc: Penta Upa <bsdboot@gmail.com>, freebsd-current@FreeBSD.org, Benjamin Kaduk <kaduk@mit.edu>, "K. Macy" <kmacy@FreeBSD.org> Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 Message-ID: <4EB22938.4050803@rice.edu> In-Reply-To: <4EB11C32.80106@FreeBSD.org> 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> <4EB11C32.80106@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/02/2011 05:32, Andriy Gapon wrote:
> [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.
*snip*
Yes, it should be. There are without question legitimate reasons for a
module to acquire a page lock.
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EB22938.4050803>