From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 10:32:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B40106566C; Wed, 2 Nov 2011 10:32:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 045D98FC0A; Wed, 2 Nov 2011 10:32:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA07975; Wed, 02 Nov 2011 12:32:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RLY7H-000DA6-7P; Wed, 02 Nov 2011 12:32:19 +0200 Message-ID: <4EB11C32.80106@FreeBSD.org> Date: Wed, 02 Nov 2011 12:32:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Benjamin Kaduk References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "K. Macy" , Penta Upa Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:32:24 -0000 [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