Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Dec 2011 18:52:29 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Request for help: how do teach module building about kernel options?
Message-ID:  <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com>
In-Reply-To: <CAJ-Vmomk4JTnZ0avRqdte9Th5F7G7x9eWTcwcd%2BT4HrcE0Mgxw@mail.gmail.com>
References:  <CAJ-Vmomk4JTnZ0avRqdte9Th5F7G7x9eWTcwcd%2BT4HrcE0Mgxw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15285562-E9BA-431B-A2C1-D0547DFB2663>