From owner-freebsd-arch@FreeBSD.ORG Sun Jan 1 01:52:47 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3889106564A; Sun, 1 Jan 2012 01:52:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE718FC08; Sun, 1 Jan 2012 01:52:47 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q011qUVJ083909 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 31 Dec 2011 18:52:30 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 31 Dec 2011 18:52:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 31 Dec 2011 18:52:30 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 01:52:47 -0000 On Dec 31, 2011, at 4:39 PM, Adrian Chadd wrote: > Hi, >=20 > I need a bit of a hand with this. >=20 > I'd like to be able to make the wlan and ath modules aware of kernel > configuration options. >=20 > For example, a kernel configuration with IEEE80211_SUPPORT_TDMA won't > build a wlan module that'll run successfully, as wlan/Makefile doesn't > know to suck in ieee80211_tdma.c . I could just wrap the whole file up > in an #ifdef, but I'd like to try and instead only build / link that > object in if it's needed. >=20 > Similarly, the ath module currently builds everything, regardless of > what options are currently enabled in the kernel configuration file. > So it'll always build ar5210, ar5211, ar5212, ar5416, ar9001, ar9002 > support, along with ath_rate_sample. Instead, I'd like to be able to > specify which HAL objects to link in, much like how you can do this > with "device ath_rfX" for the RF backends and "device ath_arX" for the > chipset support. For the integrated SoC stuff, it'd be nice to only > build a HAL which supports the relevant hardware, rather than having > to suck it _all_ in. >=20 > So, what kinds of evil ways can people dream up to achieve this? :) Build the kernel modules with the kernel and the kernel options will be = picked up. However, that only works for the opt_xxx.h files. There's not an (easy) = way to selectively include for modules with our current module system. The easy way to "work around" this is to always include the _tdma file, = and have a big ifdef around it. The 'harder' way would be to have a Makefile variable that will set all = the options in opt_foo.h as Makefile variables so you could .if based on = them. However, making that automated starts to get messy, due to the = order of inclusion. Working off the cuff, I'd propose the following API: KERNOPTS=3Dfoo baz SRC_FOO =3D foo.c SRC_BAZ =3D baz.c SRC=3D a.c b.c d.c And have the magic needed to conditionally add SRC_FOO and SRC_BAZ to = SRC in bsd.kern.mk. Warner